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 g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
