Squid-3 release cycle
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 signature.asc Description: Detta är en digitalt signerad meddelandedel
[VOTE] Squid-3.0.PRE4 release criteria
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
Re: [VOTE] Squid-3.0.PRE4 release criteria
lör 2006-05-06 klockan 12:08 +1200 skrev Doug Dixon: Option 1 - severity based We release PRE4 when all the criticals and blockers have been fixed. Over optimistic. This is the quality level required for a RC/STABLE release. 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). 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 signature.asc Description: Detta är en digitalt signerad meddelandedel
Proposal: Drop the Squid-3.0 patches page
Proposal: Drop the Squid-3 patches page. http://www.squid-cache.org/Version/v3/3.0/bugs/ It's not actively maintained and does not give much benefit to the release process until we are ready to go to STABLE state I think. If needed some of it's functionality can be resurrected from the commit logs. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Proposal: Drop the Squid-3.0 patches page
lör 2006-05-06 klockan 02:53 +0200 skrev Henrik Nordstrom: Proposal: Drop the Squid-3 patches page. http://www.squid-cache.org/Version/v3/3.0/bugs/ Can't even type tonigt.. http://www.squid-cache.org/Versions/v3/3.0/bugs/ It's not actively maintained and does not give much benefit to the release process until we are ready to go to STABLE state I think. If needed some of it's functionality can be resurrected from the commit logs. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Proposal: Drop the Squid-3.0 patches page
On Sat, 2006-05-06 at 02:53 +0200, Henrik Nordstrom wrote: Proposal: Drop the Squid-3 patches page. http://www.squid-cache.org/Version/v3/3.0/bugs/ It's not actively maintained and does not give much benefit to the release process until we are ready to go to STABLE state I think. If needed some of it's functionality can be resurrected from the commit logs. Works for me. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [VOTE] Squid-3.0.PRE4 release criteria
On Sat, 2006-05-06 at 12:08 +1200, 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. 2 or 3. I think 2 is better. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Getting 3.0 patches moving better
Hi A separate thread of activity will help get 3.0 firmed up: 1. Get the commit queue going better - there's lots of patches submitted for 3.0 waiting to be reviewed/committed. - review Target 3.0, Priority P1 bugs (which means a patch is ready for review and commit) and commit to CVS - review other Target 3.0 bugs with patches submittted, but not yet P1. Possibly P1 and commit to CVS 2. Forward port 2.5 fixes to 3.0 (Status Whiteboard contains PATCH25) - there are about 10 of these I think these are probably jobs for the core members. Henrik has volunteered to take on some of this from mid next week - are there any other takers? Cheers D
