Re: Per tuple overhead, cmin, cmax, OID - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Per tuple overhead, cmin, cmax, OID
Date
Msg-id 200206082201.g58M1Av13891@candle.pha.pa.us
Whole thread Raw
In response to Re: Per tuple overhead, cmin, cmax, OID  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)
Re: Per tuple overhead, cmin, cmax, OID
List pgsql-hackers
Tom Lane wrote:
> Uh guys ... what I *said* was:
> 
> > I think we are planning to go beta in late summer (end of August, say).
> > Probably in July we'll start pressing people to finish up any major
> > development items, or admit that they won't happen for 7.3.
> 
> By which I meant that in July we should start hounding anyone who's got
> major unfinished work.  (Like, say, me, if the schema changes are still
> incomplete then.)  Not that we won't accept the work when it gets here,
> just that that'll be the time to start demanding closure on big 7.3
> changes.

OK.

> And yes, I *would* be pretty upset with the idea of applying major
> patches in the last weeks of August, if they are changes that pop up
> out-of-the-blue at that time.  If it's finishing up work that the
> community has already approved, that's a different scenario.  But big,
> poorly-reviewed feature additions right before beta are exactly my idea
> of how to mess up that reputation for stability that Marc was touting...

Yes, but there is a downside to this.  We have trouble enough figuring
out if a patch is a "feature" or "bug fix" during beta.  How are people
going to decide if a feature is "big" or not to work on during August?
It has a paralyzing effect on our developers.  

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.

We have beta for testing.  That's were our reliability comes from too. 
And last beta, we did almost nothing because we had shut down
development so early, and it dragged because there _wasn't_ a clear line
between development time and beta.

So, I we should:
Warn people in July that beta is September 1 and all featureshave to be complete by then, or they get ripped out.
Reject non-complete patches during August, meaning acceptedpatches in August have to be fully functional features;
nopartialpatches and I will work on the rest later.
 
Vote on any patches where there is disagreement.

So, in summary, for me, August patches have to be 100% complete.  That
takes the guess work out of the deadline.  There isn't the question of
whether we will accept such a feature or not.  The burden is on the
developer to provide a 100% complete patch.

--  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: Roadmap for a Win32 port
Next
From: Tom Lane
Date:
Subject: Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)