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:

Previous
From: Daniel Farina
Date:
Subject: Re: Should we add crc32 in libpgport?
Next
From: Robert Haas
Date:
Subject: Re: Why is CF 2011-11 still listed as "In Progress"?