From: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Manfred Koizar <mkoi-pg(at)aon(dot)at>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Project scheduling issues (was Re: Per tuple overhead, |
Date: | 2002-06-09 16:28:22 |
Message-ID: | 20020609132627.S32655-100000@mail1.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 9 Jun 2002, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)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 ...
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-09 16:30:21 | Re: Timestamp/Interval proposals: Part 2 |
Previous Message | Tom Lane | 2002-06-09 15:59:55 | Re: revised sample SRF C function; proposed SRF API |