Skip site navigation (1) Skip section navigation (2)

Re: 8.5 development schedule

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.5 development schedule
Date: 2009-07-01 15:38:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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 

 > 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 

Josh Berkus
PostgreSQL Experts Inc.

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-07-01 15:41:18
Subject: Re: single bit integer (TINYINT) revisited for 8.5
Previous:From: Caleb CushingDate: 2009-07-01 15:19:48
Subject: single bit integer (TINYINT) revisited for 8.5

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group