Re: Project scheduling issues (was Re: Per tuple overhead,

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, 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-10 17:29:13
Message-ID: 200206101729.g5AHTEW24184@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 ...

Yes, this was exactly my point. By slowing down in August, we enter
that "almost beta" period where there is uncertainty over what should be
worked on. I know myself I am uncertain what is appropriate to work on,
so I usually end up doing nothing, which is a waste.

I think the only message should be "finish before the end of August".
People can understand that, and it is under the control of the
contributor. The message "no big patches in August" is too imprecise and
leads to uncertainty.

Of course, if we don't finish by the end of August, our new message may
be "finish before the end of September". This brings up another point.
We have delayed beta to wait for single patches in the past, usually a
week at a time. When that week drags to two, and then four, we have
lost development time. If we had just said "four weeks" from the start,
people could have continued development, knowing they had a month, but
our one-week-at-a-time strategy basically holds up the whole group
waiting for single developer to finish a patch. What I am suggesting is
that our small delays for beta are hurting us _if_ the delay drags
longer than anticipated, and we keep pushing back the deadline. In such
cases, we would be better just choosing a longer deadline from the
start. Perhaps we should have delays that are a month at a time.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-06-10 17:33:01 Re: Project scheduling issues (was Re: Per tuple overhead,
Previous Message Hannu Krosing 2002-06-10 17:18:44 Re: Timestamp/Interval proposals: Part 2