Squid-3.0.PRE4 release plan

From: Doug Dixon <doug.dixon@dont-contact.us>
Date: Sun, 7 May 2006 08:27:03 +1200

Okay - let's go with this:

1. Our aim is to release Squid-3.0.PRE4 snapshot over the weekend of
10/11 June.

2. We will work to a fixed list of bugs: those that have "PRE4" in
the Status Whiteboard.
http://tinyurl.com/kaoqq

This list contains the nine criticals/blockers as of today, so we are
still aiming at the most serious bugs.
However, the list won't grow just because we find more. PRE4 will
roll as soon as we fix them all.

If we hit the target date and we haven't fixed all of these bugs, the
plan is still to make a release, as there is still value in this. If
we have _nearly_ met our bug target, and a few more days are needed
to tie things up, then we may extend the deadline once by up to one
week.

I will monitor the rate of progress, and adjust the goal if it starts
to look either too easy or too difficult. Let's see how it goes.

While the focus is on fixing the bugs which are blocking PRE4, it
would obviously be great to fix as many of the others as possible. So
if you've got the time and inclination to fix bugs, but the ones on
the critical path are either too much work or are already taken,
please feel free to squash the smaller ones.

If we have a manpower problem, but otherwise a good rate of progress,
it may be worth trying to attract others we know may be interested in
helping.

Let me know if this sounds like a plan

Cheers
Doug

On 6 May 2006, at 12:08, Doug Dixon wrote:

> All
>
> I aim to get Squid-3.0.PRE4 released in four to six weeks' time.
>
> The list of bugs to be fixed in 3.0 is here:
> http://tinyurl.com/f56qm
>
> This includes bugs that were discovered in 2.5 but which still need
> fixing in 3.0.
>
> I am considering three options for setting the Squid-3.0.PRE4
> release criteria:
>
> -----
>
> Option 1 - severity based
> We release PRE4 when all the criticals and blockers have been fixed.
>
> Option 2 - hand-picked
> We hand pick a fixed list of bugs which we think we can fix within
> a reasonably short time. We release when they are all fixed. No
> other bugs can enter the list once it is picked.
>
> Option 3 - time based
> We release PRE4 on June 1, and fix whatever bugs we can until then
> (blockers first).
>
> -----
>
> Option 1 could leave us vulnerable to a never-ending flow of new
> criticals/blockers. I understand something like this happened in
> the past. Are we still vulnerable to this or has the real level of
> serious bugs dropped to a quantifiable level yet? The benefit of
> this option is that PRE4 "means" something positive about the level
> of known defects. But if the cost is too high, e.g. we never get
> PRE4 out, then I'm not prepared to do this.
>
> Options 2 and 3 have the benefit of having fixed criteria, but at
> the cost of PRE4 not meaning much about its quality. E.g. why don't
> we release PRE4 today?
>
> In principle I prefer Option 1, but if it's too risky then I'd go
> for Option 3.
>
> Please could you reply to this email and vote for Option 1, 2 or 3
> with brief reason.
>
> And as Henrik says, if you've got new stuff in the pipeline, please
> shout now. We just need to agree which PRE it goes into - whether 4
> or later.
>
> Hope this all sounds okay.
>
> Cheers
> Doug
>
>
> On 6 May 2006, at 03:18, Henrik Nordstrom wrote:
>
>> For those who have not been on the #squid-dev IRC channel lately I
>> can
>> tell that the last weeks has been quite interesting.
>>
>> The most significant news is that Doug Dixon (aka ganso on the
>> IRC) has
>> volunteered for the role as Squid-3.0.PRE4 release manager. Expect a
>> message from him shortly presenting his ideas on how we can get
>> there.
>>
>> To follow up on a few questions from him regarding the current state:
>>
>> The Squid-3 tree is currently best described as in DEVEL state,
>> even if
>> it is carrying a PRE tag. The reason to this is that the original
>> Squid-3.0 release cycle could not be met due to various events and
>> the
>> tree had to be unlocked again to allow for new developments.
>>
>> The goal now should be to be able to enter PRE state again, with
>> ultimately a PRE4 release from where we can work towards the STABLE
>> release. I do not think there is any major changes waiting in
>> queue for
>> getting into Squid-3, and imho "minor"/"isolated" features like
>> WCCPv2
>> or a improved COSS may well get into the tree during a PRE cycle. But
>> there is a quite long list of bugs, both verified and to be analyzed
>> ones. Some critical, many not so critical ones..
>>
>>
>> Developers having new features in queue which they would like to get
>> into Squid-3.0 please speak up now, allowing for Doug to do his job
>> proper. As for all of us his time is somewhat limited and the
>> timeframe
>> currently considered for a PRE4 release is not very distant.
>>
>> Regards
>> Henrik
>
Received on Sat May 06 2006 - 17:25:45 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:04 MDT