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

From Bruce Momjian
Subject Re: Project scheduling issues (was Re: Per tuple overhead,
Date
Msg-id 200206101729.g5AHTEW24184@candle.pha.pa.us
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>)
List pgsql-hackers
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 ...

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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [SQL] Efficient DELETE Strategies
Next
From: Bruce Momjian
Date:
Subject: Re: Project scheduling issues (was Re: Per tuple overhead,