Re: Feature Freeze date for 8.4 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Feature Freeze date for 8.4
Date
Msg-id 1193209172.4242.97.camel@ebony.site
Whole thread Raw
In response to Re: Feature Freeze date for 8.4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2007-10-23 at 19:42 -0400, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > Plus, for the developers and other people who really need to be 
> > bleeding-edge, this new plan would result in less-unstable snapshots every 
> > 2 months with defined feature sets which someone who wanted to run them at 
> > their own risk could.  Which would result in more bug reports, earlier, 
> > for us (and lots of forwarding the canned 
> > "milestone-releases-are-not-stable" canned e-mail).
> 
> Hmm, I was not envisioning that we'd produce any sort of "release"
> corresponding to these checkpoints.  I see it only as a a way to
> (a) discipline ourselves to not let patches go unreviewed/uncommitted
> for long periods, and (b) encourage developers to submit relatively
> small patches rather than enormous six-months-of-work ones.
> 
> Since there are always bugs, and we're certainly not going to schedule a
> round of formal beta testing right after each commit-fest, I should
> think that tarballs made right after a commit-fest would be particularly
> unlikely to be good candidates for non-developer use.
> 
> (Actually, it might be the case that a CVS snap from just *before*
> a commit-fest would be the most stable development-cycle code, since
> there'd have been time to shake out bugs committed in the previous
> fest... but we're even less likely to do beta testing on that.)

+1

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Feature Freeze date for 8.4
Next
From: ITAGAKI Takahiro
Date:
Subject: VACUUM always makes all pages dirty