Re: 8.5 development schedule

> Ugh, I disagree.  I agree that we were too generous with letting
> people rework patches while the CommitFest was in progress (mostly, we
> let people drop off the map for 3 weeks and then come back and say,
> oh, here's my revised version).  But you have to allow a certain
> amount of reworking as the CommitFest progresses, I think.  Otherwise,
> it just takes way too long to get anything done.

Sure.  The key is "a *certain amount* of reworking".  Not failing to 
respond to review for 3 weeks at a time.  Not introducing APIs or syntax 
extensions which have never been discussed on -hackers before.  Not 
extensive performance testing.  Not saying "here's 3 parts out of 5 of 
the patch, I'll have the other two by the 15th". Not sumbitting a patch 
with no written specification or (for user-facing features) documentation.

That is, the *submitter* should at least think the patch is ready to go.  If people are submitting stuff they *know*
isn'tready to commit, it 
 
should be with a "WIP" flag, which to the reviewers says "review this 
last, or not at all if we run out of time".

And, even if the submitter is being responsive, if we've spent 30 days 
being back-and-forth with the patch, it's just not ready.  Dragging that 
out to 60 days doesn't, according to our history, help.
> I also believe, although I cannot prove it, that it would have> increased the pressure to get the remaining items
dealtwith.  When> there are 100 patches, everyone can say "oh, well it doesn't matter> whether I get this taken care of
today,because there will still be 99> other patches".  When there are 3 patches, that argument doesn't hold> water.
 

I agree.  Closing out 11/08 accelerated once we were down to the last 5 
patches.
> If we need to effectively shut down new development for seven> months at the end of a release, in addition to the
interimcommit> fests, we'd better get a handle on why, so that can change.  To what> do you attribute the extended time
neededto handle the final CF?> How can that be made better?
 

Exactly.  What I think we should be moving towards is the idea that 
*any* commitfest could, with another 30 days of housekeeping, become a 
final release.  The only way to release in a timely fashion is to always 
be ready to release -- this is not just my opinion, but the experience 
of the Ubuntu, Parrot, and several other projects.

Let me point out a worrisome trend:

7.2: 10 months
7.3: 9 months
7.4: 12 months
8.0: 13 months
8.1: 11 months
8.2: 13 months
8.3: 14 months
8.4: 16 months

That's a dangerous-looking progression.  What's worse is that the 
increasing time has always been associated with post feature-freeze; 
i.e. the not-fun post-development period.

Until we embrace the idea that patches will get integrated or rejected 
in a timely fashion, and that we *can* make a target release date, we 
won't.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com