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
