9.2 schedule - Mailing list pgsql-hackers

At the developer meeting last week:  
http://wiki.postgresql.org/wiki/PgCon_2011_Developer_Meeting there was 
an initial schedule for 9.2 hammered out and dutifully transcribed at  
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Development_Plan , and 
the one part I wasn't sure I had written down correctly I see Robert 
already fixed.

There was a suggestion to add some publicity around the schedule for 
this release.  There's useful PR value to making it more obvious to 
people that the main development plan is regular and time-based, even if 
the release date itself isn't fixed.  The right time to make an initial 
announcement like that is "soon", particularly if a goal here is to get 
more submitted into the first 9.2 CF coming in only a few weeks.  Anyone 
have changes to suggest before this starts working its way toward an 
announcement?

The main parts of the discussion leading to changes from the 9.1 
schedule, as I recall them, are:

-Shooting for a slightly earlier branch/initial 9.2 CommitFest in June 
helps some with patch developer bit-rot, and may let developers who are 
focused on new features be productive for more of the year.  The 
perception that new development is unwelcome between the final CF and 
version release seems to have overshot a bit from its intention.  It's 
not the best period to chat on this list, with many people distracted by 
release goals.  But some people just aren't in the right position to 
work on alpha/beta testing and stability work then, and the intention 
was not to block them from doing something else if that's the case.  (A 
similar bit brought up during one of the patch prep talks is that review 
is also welcome outside of a CF, which isn't really clear)

-The last CF of the release is tough to reschedule usefully due to 
concerns about December/beginning of the year holidays.

-Given that work in August is particularly difficult to line up with 
common summer schedules around the world, having the other >1 month gap 
in the schedule go there makes sense.

As for why there aren't more changes, it's hard to argue that the 9.1 
process was broken such that it needs heavy modification.  There were a 
large number of new features committed, people seem satisfied with the 
quality of the result so far, and the schedule didn't go too far off the 
rails.  Outside of the manpower issues (which are serious), the sections 
that strained the most against problems seem really hard to identify 
with anything other than hindsight.  The tension between "ship it" and 
"make the release better" is a really fundamental one to software 
development.

The two main ideas that pop up regularly, organizing more CommitFests or 
making them shorter, are both hard to adopt without more active 
volunteers working on review (both at the initial and committer level) 
and an increase in available CF manager time.  An idea I heard a couple 
of people suggest is that it would take a CF manager focused exclusively 
on the "patch chasing" parts of the role--not someone who is also trying 
to develop, commit, or review during the CF--before this would be 
feasible to consider.  Some sort of relief for making that role less 
demanding is needed here, before it's practical to schedule those even 
more often.

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