Re: Per tuple overhead, cmin, cmax, OID

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: Per tuple overhead, cmin, cmax, OID
Date: 2002-06-08 22:01:10
Message-ID: 200206082201.g58M1Av13891@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 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.

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-06-08 23:40:58 Project scheduling issues (was Re: Per tuple overhead, cmin, cmax, OID)
Previous Message Bruce Momjian 2002-06-08 21:48:12 Re: Roadmap for a Win32 port