Re: [VOTE] Squid-3.0.PRE4 release criteria

Hi,

On 6/05/2006 10:05 p.m., Guido Serassio wrote:
>> Combination of 2 & 3 is my vote.
>>
>> Start with a hand picked list and a target date. Adjust the list over
>> time, removing items found to not be realistic for the target date and
>> add items which is found sufficiently important, and if necessary to
>> preserve reasonable faith in the release adjust the time (limited +1
>> week or so, no limit on early release when goals met).
>>
>> This is a scaled down version of the process currently used for the
>> STABLE releases.
>>
>> Regards
>> Henrik
>
> I fully agree with the Henrik's vote.
>
> Regards
>
> Guido

Me too. Having a reasonably definite date known in advance with only a few days
room to shift it will hopefully encourage more of a sense of working towards a
target. Some of the bugs in bugzilla would likely hold the release up for
months if we were to try and fix them all before the next PRE.

Additionally, why I'm less inclined towards option 1 is that at this early stage
I think it's well worth just having list of *known* bugs with good bug reports,
even if we haven't actually fixed them. Given the very limited testing of the
code now, there are likely to be many currently unknown bugs show up anyway as
soon as people start banging on the code again, so aiming for no criticals or
high priority bugs after so many changes is likely to be somewhat futile ;-)

In terms of dates, we'll also need some resource to be able to respond to the
new bugs that people find immediately after the release, whatever date that
turns out to be.

Btw, thanks for taking on this task, Doug.

reuben
Received on Sat May 06 2006 - 04:44:19 MDT