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: