Hi, First, sorry to have raised the issue in the first place. It wasn't my intention to start a release policy war :-)
On Wed, 2009-09-16 at 04:21 -0400, Rein Henrichs wrote: > As I'm sure you're all aware, are two basic tensions in release > management: Pick a set of features, or pick a deadline. We seem to be > in agreement for the release strategy of major puppet releases (we use > the latter) but there is some advocacy on both sides for smaller > (point-point) releases. > > > I would like to suggest compromise solution that we appear to be > converging on anyway: Mark certain tickets as release blockers, or use > a certain priority level (high or greater) as an ad-hoc indicator that > a ticket is blocking (per James); ensure that they are fixed; and then > include any other completed tickets when packaging the release. This > trades a certain amount of timeline certainty for a greater certainty > that these issues will be addressed in the given release. This seems > like a fair trade for minor releases. Looks good to me. > Markus raised an objection to my use of the term "blocker" in a call > today, but it seems like the appropriate term to use for a ticket that > has otherwise been described as "show-stopping" or "really should be > fixed [for this release]". I'm also not married to this term if > swapping it out will help us arrive at a good solution. I really feel that we shouldn't release something that we know has verified fixable critical issues (either security, loss of functionnality or simply high traffic). Of course there is no point blocking a release if we know we can't fix those bugs in a short time. So my advice would be to not be strict on the release policy: if there are show stopper, fix as much as we can, possibly slipping the release date by a week (but not more). If a show stopper comes the day of the release or before but we feel it isn't possible to fix it in a timely way (ie without extending the release date), then too bad, the release will go out anyway. I'm not sure having strictly firm release date is a plus for the users. I'm almost sure they'd prefer a more bug-free release, even though they'll have to wait a little bit more to have it. And, since we all agree to not have features in sub-releases, only bug-fixes, I think we shouldn't see again what happened to 0.24.x (for which I share my part of the responsibility for having released some language features in a sub-release). > How does this feel to you folks? I'd tend to agree with you. -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
