Re: Project scheduling issues (was Re: Per tuple overhead, - Mailing list pgsql-hackers

On Sat, 8 Jun 2002, Bruce Momjian wrote:

> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Now, I don't want to apply a partially-implemented feature in the last
> > > week of August, but I don't want to slow things down during August,
> > > because the last time we did this we were all looking at each other
> > > waiting for beta, and nothing was getting done.  This is the paralyzing
> > > effect I want to avoid.
> >
> > Well, my take on it is that the reason beta was delayed the last two
> > go-rounds was that we allowed major work to be committed in an
> > incomplete state, and then we were stuck waiting for those people to
> > finish.  (The fact that the people in question were core members didn't
> > improve my opinion of the situation ;-))  I'd like to stop making that
> > mistake.
>
> I am going to recommend disabling features that people can't fix in a
> timely manner during beta.  Sounds harsh, but we can't have the whole
> project waiting on one person to have a free weekend.  If they can
> generate a patch, we can re-enable the feature, but we need to get some
> discipline for everyone's benefit. I don't think any of us wants to be
> embarrassed by the beta duration again.

I wasn't embarrassed by it ... when I talk to ppl asking about QA on
PostgreSQL, I quite proudly point out that we'd rather delay then release
something we aren't confident about *shrug*

> It emphasizes August as primarily finish-up time.  And there is that
> "pre-approved" part I don't like.  Feature has to be done by the end of
> August, doesn't matter whether it is approved or not.  If someone wants
> to start and complete a feature during August, "go ahead" is my moto.

Personally ... I'm really curious as to why you are even trying to
'formalize' stuff that has been done for years now ... end of August rolls
around and someone submits a feature patch, we do as we've always done ...
we discuss its merits, and its risk factor ... if it presents too high a
risk, it gets put on the 'patch stack' for the next release ... or do you
think our judgement in such matters is such that we have to formalize/set
in stone this common sense stuff beforehand?

I *really* wish ppl would stop harping on the length of the last beta
cycle ... I will always rather delay a release due to an *known*
outstanding bug, especially one that just needs a little bit more time to
work out, then to release software "on time" ala Microsoft ...

Hell, you are trying to set in stone when beta starts (end of august) ...
but with some of the massive changes that we tend to see over the course
of a development project, for all we know, Tom will be 90% finished
something and only need another week to get it complete ... personally,
he's one of many whose code I wouldn't question, so giving another week to
get it done and in, IMHO, is perfectly acceptable ... but, for what you
are trying to get set in stone, it wasn't finished by Sept 1st, so we'll
throw it all out until the next release ...

Right now, Sept 1st is the "preferred date to go beta" ... when Sept 1st
rolls around, like we've always done in the past, we will review that and
if we need to delay a little, we will *shrug*