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't ready 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 dealt with. 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 interim commit
> fests, we'd better get a handle on why, so that can change. To what
> do you attribute the extended time needed to 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
