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 4F14BA5E.1020602@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"?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 01/16/2012 02:42 PM, Robert Haas wrote:
> But, I've noticed that nothing good comes of me pressing my own view
> too hard.  Either we as a community value having the CommitFest wrap
> up in a reasonable period of time, or we don't.  If we do, then let's
> make it happen together.  If we don't, then let's resign ourselves now
> to the fact that 9.2 will not hit the shelves for a very long time.

I think this is getting more predictable simply based on having some 
history.  The trail blazing you led here for some time didn't know what 
was and wasn't possible yet.  I feel that the basic shape of things, 
while still fuzzy in spots, is a lot more clear now.

We need to have schedule goals.  There needs to be a date where we 
switch toward a more aggressive "is someone going to commit this soon?" 
stance on things that are still open.  At that point, someone needs to 
be the person not afraid to ramp up pressure toward returning things 
that just aren't going to make it to commit quality.  That's a thankless 
task that rarely leaves anyone involved happy.

But this project won't easily move to "ship on this date" instead of 
"ship when it's ready", and I don't want that to change.  There's two 
sides to that.  The quality control on most of the 100% date driven 
release software I use is terrible.  The way the CF schedule is lined up 
now, there's enough margin in the schedule that we can handle some drift 
there, while still keeping the quality standards high.  The currently 
open CF is probably going to take at least 6 weeks.  That doesn't change 
the fact that hard decisions about return vs. continue toward possible 
commit should be accelerating by or before the 4 week mark.

The other side to this is that when some big and/or hard features land 
does impact PostgreSQL's adoption.  To close some of them, you almost 
need the sort of focus that only seems to come from recognizing you're 
past the original goal date, this one big thing is holding up forward 
progress, and everyone who can should be pushing on that usefully to 
wrap it up.  Could the last 9.1 CF have closed up 1 to 2 weeks earlier 
if Sync Rep had been bumped?  Probably.  Was it worth going off-schedule 
by that much so that it did ship in 9.1?  I think so.  But with every 
day marching past the original goal, the thinking should turn toward 
what simplified subset is commit quality.  If there's not a scaled down 
feature some trimming might extract and get to commit quality--which was 
the case with how Sync Rep ended up being committed--that one needs to 
close.  The couple of weeks over target 9.1 slipped is as bad as we can 
let this go now.

I made one big mistake for 2011-11 CF I want to learn how to avoid next 
time.  When we went past the schedule goal--closing on 12/15--I got most 
of the patches closed out.  What I should have done at that point is 
push toward alpha3 release, even though there were ~5 things still 
open.  The fact that some patches in that CF are still being tinkered 
with shouldn't delay a date-driven alpha drop.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Review of: pg_stat_statements with query tree normalization
Next
From: Scott Mead
Date:
Subject: Re: IDLE in transaction introspection