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

From Marc G. Fournier
Subject Re: Per tuple overhead, cmin, cmax, OID
Date
Msg-id 20020608210258.K27088-100000@mail1.hub.org
Whole thread Raw
In response to Re: Per tuple overhead, cmin, cmax, OID  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Per tuple overhead, cmin, cmax, OID  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Sat, 8 Jun 2002, Bruce Momjian wrote:

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

How is this any different then our other releases?  I think you've totally
lost me as to where the problem is ... reading your above, you are
suggesting that ppl don't work on big projects during the month of August,
since it might not get in for the release?  We've never advocated that
before, nor do I believe we should at this point ... in fact, I think its
about time we start dealing with beta using the tools that we have
available ...

Beta starts, we branch out a -STABLE vs -DEVELOPMENT branch in CVS ... we
release a beta1 and deal with bug releases as they come in, followed by a
beta2 until we are ready for release ... I think everyone is old enough
now to be able to decide whatfixed have gone into -STABLE that should be
reflected in -DEVELOPMENT, no?  Our mistake last release wasn't how long
beta lasted, but how long we stalled development ...




pgsql-hackers by date:

Previous
From: "Josh Berkus"
Date:
Subject: Re: Timestamp/Interval proposals: Part 2
Next
From: Tom Lane
Date:
Subject: Re: revised sample SRF C function; proposed SRF API