New proposed release cycle for IcedTea-Web

[Jiri Vanek]

On 05/22/2012 11:00 PM, Danesh Dadachanji wrote:
>
>
> On 22/05/12 01:08 PM, Deepak Bhole wrote:
>> * Jiri Vanek<jvanek at redhat.com> [2012-05-22 11:42]:
>>> On 05/22/2012 05:22 PM, Deepak Bhole wrote:
>>>> Hi Everyone,
>>>>
>>>> The past, IcedTea-Web releases have been rather sporadic and I would like
>>>> to address this with a firm release cycle.
>>>>
>>>> I was thinking that from here on, we do a forced release every 4-6
>>>> months, with branching happening 3 weeks before release.
>>>>
>>>> Whichever period we pick, the release date will be firm. The only
>>>> exceptions allowed will be critical blockers/regressions. If features do
>>>> not make it in before branching, they get pushed to next release.
>>>>
>>>> With 6 months, the next release will be on September 4th 2012.
>>>> With 4 months, the next release will be on July 3rd 2012.
>>> With 6months I will be able to finish SplashScreen, with 4 I'm afraid I will not finish it in
>>> time :(
>>>
>>
>> How about 5-mo for this one since it is rather short notice? With 5, we
>> would release on August 7th and branch around July 17th, so just below 2
>> months from now for branch.

yap should be ok.

>>
>
> I'm fine with having shorter release cycles as long as the process does not require _that much_
> work. As far as I understand, the main annoyance is going through the regression tests [1] so if
> this is the case, 4-6 month release cycles are fine by me. IMO 6 months is fine just so that distro
> packagers don't have to go through more hassle, on the condition that we run through regression
> tests more often!
>
> [1] which IMHO should be done more often than every 4 months anyways. I would say after X changesets
> (perhaps feature-related changesets only).
>
>>>>
>>>> I had 6 months in mind initially, but given the pace at which things are
>>>> moving, I think 4 is more suited in the short-term for the next 2-3
>>>> releases.
>>> So my suggestion here is 4-6 according to features :)
>>
>> I think that would contradict the notion of non-negotiable release
>> cycles. An open-ended "4-6 according to features" once again starts to
>> drag us into feature based releases which I would like to avoid as it
>> has not worked for us in the past.

Ok. I have lack of  experiences here. So as you wish!

>>
>
> +1 for having fixed dates too, this way the regression dates are gone through at least once every
> 4-6 months.

There is huge effort to made all regression tests (including remote/foreign-bianries and visual) 
automated.  So with some luck they will be run daily....

J.