On Monday 23 June 2003 10:43 am, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > Here's a sure to be wildly unpopular suggestion:
> >
> > Make the deciding factor for the next release support of "foo" (foo can
> > be win32, pitr, replication, 2PC, whatever...).
>
> We've done that before (see WAL in 7.1), with unhappy results.
well, I did say it would be wildly unpopular ;-)
> The
> fundamental problem with it is that towards the end of the cycle,
> other developers don't know how to schedule their time, because they
> don't know when feature freeze is really going to be. People end up
> twiddling their thumbs while the schedule slips a few days at a time.
>
Ok, what if feature freeze comes 1 month after completion of "foo" feature.
This way the release is still feature dependent, but people arn't sitting
around day by day waiting for foo, and they also don't have to worry about
getting caught in the middle of something when foo gets done. (i'm kind of
picking 1 month arbitraily, this could be two weeks if that works better).
> The target-date-based approach we've taken in the last couple of
> releases seems much more productive.
>
productive on a small scale; for sure. productive for large scale features...
well, that's why it's being discussed.
Robert Treat