Re: Why is CF 2011-11 still listed as "In Progress"? - Mailing list pgsql-hackers
From | Greg Smith |
---|---|
Subject | Re: Why is CF 2011-11 still listed as "In Progress"? |
Date | |
Msg-id | 4F14E458.80704@2ndQuadrant.com Whole thread Raw |
In response to | Re: Why is CF 2011-11 still listed as "In Progress"? (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Why is CF 2011-11 still listed as "In Progress"?
Re: Why is CF 2011-11 still listed as "In Progress"? |
List | pgsql-hackers |
On 01/16/2012 08:27 PM, Robert Haas wrote: > the last two release cycles I've put huge amounts of energy > into trying to get the release stable enough to release before July > and August roll around and everybody disappears. It didn't work, > either time. If that's not going to happen anyway, then there's not > really much point in getting stressed about another week or two. Adjusting that expectation is another side to pragmatism based on recent history I think needs to be acknowledged, but is unlikely to be improved on. 9.0 shipped on September 20. 9.1 shipped on September 11. If we say the last CF of each release is unlikely to wrap up before early March each year, that's 6 months of "settling" time between major feature freeze and release. So far that seems to result in stable releases to be proud of, on a predictable enough yearly schedule. Trying to drop the settling time has been frustrating for you, difficult to accomplish, and I'm unsure it's even necessary. Yes, there are some users of PostgreSQL who feel the yearly release cycle is too slow. As I was saying upthread, I don't see any similarly complicated projects doing better whose QA hasn't suffered for it. Are there any examples of serious database software that navigate the new features vs. low bug count trade-off as well as PostgreSQL, while also releasing more often? The one thing that really wasn't acceptable was holding off all new development during the entire freeze period. Branching 9.2 much earlier, then adding the June CommitFest last year, seems to have released a lot of the pressure there. Did it push back the 9.1 release or drop its quality level? Those two things are not decoupled. I think we'd need to look at "fixes backported to 9.1 after 9.2 was branched" to see how much benefit there was to holding off release until September, instead of the July/August time-frame you were pushing for. Could 9.1 have shipped in July and kept the same quality level? My guess is that the additional delay had some value for smoking bugs out. Would have to actually look at the commit history more closely to have an informed opinion on that. I find your tone during this thread a bit strange. I see the way you in particular have pushed on formalizing the CommitFest process the last few years to be a big success. I've been staring at the approaching work left on 9.2, finding a successful track record that outlines a game plan for what's left, even seeing enough data for rough metrics on how long things should take. That's a huge step forward for everyone compared to the state of things a few years ago, where the state of the art was a patch queue in everyone's mailbox, and new submitters had no idea when they'd get feedback. Your hoping that it was possible to get releases out in the summer of each year hasn't worked out so far. I know that was frustrating for you, but I certainly don't see that as a failure; just something we've now seen enough feedback on to acknowledge and accept as impractical. If the flood of last minute submissions right before the freeze submission deadline takes 6 weeks to clear now, that still seems a whole lot better than what I remember of 8.3 and 8.4 development. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
pgsql-hackers by date: