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

From Marc G. Fournier
Subject Re: Project scheduling issues (was Re: Per tuple overhead,
Date
Msg-id 20020609132627.S32655-100000@mail1.hub.org
Whole thread Raw
In response to Re: Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 9 Jun 2002, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> > 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 ...
>
> I don't think that's at issue here.  No one was suggesting that we'd
> force an *end* to beta cycle because of schedule issues.  We ship when
> we're satisfied and not before.  I'm saying that I want to try to
> *start* the beta test period on-time, rather than letting the
> almost-beta state drag on for months --- which we did in each of the
> last two cycles.  Development time is productive, and beta-test time
> is productive, but we're-trying-to-start-beta time is not very
> productive ...

Agreed on all accounts ... which is why this time, I want to do a proper
branch when beta starts ... hell, from what I've seen suggested here so
far, we have no choice ... At least then we can 'rip out' something from
the beta tree without having to remove and re-add it to the development
one later, hoping that they're changes haven't been affected by someone
else's ...




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: revised sample SRF C function; proposed SRF API
Next
From: Tom Lane
Date:
Subject: Re: Timestamp/Interval proposals: Part 2