Suggestion for Handling Pre-Releases

[Itamar Heim]

On 01/15/2014 10:38 AM, Livnat Peer wrote:
> On 01/14/2014 10:31 PM, Itamar Heim wrote:
>> On 01/14/2014 07:51 PM, Livnat Peer wrote:
>>> On 01/14/2014 05:26 PM, Itamar Heim wrote:
>>>> On 01/14/2014 11:15 AM, Livnat Peer wrote:
>>>>> On 01/13/2014 09:35 PM, Brian Proffitt wrote:
>>>>>> Kiril, Dave and I were discussing how to update the community on
>>>>>> pre-releases, while still keeping newer users on track to download
>>>>>> and install the most stable release. What would be some suggestions
>>>>>> on how to ensure new users are getting stable and veteran users are
>>>>>> getting to development releases, if they want? We were pondering a
>>>>>> separate link on the home page to something like this
>>>>>> (http://www.ovirt.org/Download_devel_release), but other ideas are
>>>>>> more than welcome.
>>>>>>
>>>>>> Ideally, we want to make the onboarding process as (a) efficient and
>>>>>> (b) easy as possible.
>>>>>>
>>>>>
>>>>> Brian,
>>>>>
>>>>> Just making sure I got the question right, we are looking on a way to
>>>>> make the alpha/beta build more available for users?
>>>>>
>>>>> If that is the question, how about the jboss( Wildfly :) ) approach
>>>>> http://wildfly.org/downloads/
>>>>>
>>>>>
>>>>> Livnat
>>>>>
>>>>>> Looking forward to hearing from you,
>>>>>> BKP
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Arch mailing list
>>>>> Arch at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>>
>>>>
>>>> I think Lior was talking about making this visible via the webadmin.
>>>
>>> That was my understanding as well.
>>>
>>>> I think the right way of doing this is not related to the web site,
>>>> rather to the ovirt engine showing if there are newer (relevant)
>>>> packages in the engine-check-update queue.
>>>
>>> I don't think the two are exclusive or, I think we should have both.
>>> I rather d/l bits from a website over clicking on d/l buttons in the app.
>>>
>>
>> d/l bits from the website doesn't work for rpm based deployments for
>> updates.
>> the website download link should point to latest stable release, maybe
>> also to latest unstable (next version alpha/beta/etc.).
>>
>> the webadmin should show an existing admin that there is a newer version
>> available, without the admin visiting the website.
>
> The webadmin should indicate that there are new bits, for getting them
> you need to go to the website and d/l them.

download what - 50 rpm's?

engine should just execute yum update on the engine/hosts when asked by 
admin after showing there are updates.

>
> The original question was how do we add exposure to the pre-releases
> which are not available today for users, and the webadmin can not be the
> only way to get alpha/beta release.

this should be prominent on the home page, i agree.