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

From Tom Lane
Subject Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)
Date
Msg-id 21096.1023579658@sss.pgh.pa.us
Whole thread Raw
In response to Re: Per tuple overhead, cmin, cmax, OID  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Project scheduling issues (was Re: Per tuple overhead,  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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.

> So, I we should:
>     Warn people in July that beta is September 1 and all features
>     have to be complete by then, or they get ripped out.
>     Reject non-complete patches during August, meaning accepted
>     patches in August have to be fully functional features; no
>     partial patches and I will work on the rest later.

I thought that was more or less the same thing I was proposing...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Per tuple overhead, cmin, cmax, OID
Next
From: "Josh Berkus"
Date:
Subject: Re: Timestamp/Interval proposals: Part 2