Josh Berkus <[EMAIL PROTECTED]> 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.)

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to