On Mon, Jun 4, 2012 at 7:11 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Mon, Jun 4, 2012 at 7:02 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: >> I think marking both as Rejected would be an accurate reflection of >> python-dev's collective opinion. > > Slight correction: I think it would accurately reflect python-dev's > *divided* opinion, using the principle of "Status quo wins a > stalemate". The costs for either scheme are high, the benefits are not > proven, thus the default is to stick with the status quo. > > Releasing alphas early, OTOH, doesn't require any real changes to our > development process at all, aside from imposing a bit more discipline > on trunk development in the first 12 months of the release cycle (I'm > inclined to place that particular detail on the "benefit" side of the > ledger, rather than the "cost" side). The *total* number of releases > from the release managers and installer builders shouldn't increase > much, if at all - I'd suggest we just stick with Georg's practice of 4 > alpha releases, and merely space them out over the course of the > release cycle rather than clustered together at the end. > > If Larry doesn't want to try this for 3.4, then I'll most likely > volunteer as 3.5 RM and try it out then. After an off-list discussion with Larry, I'm now planning to expand on this concept in PEP form (superceding 413). There's actually a little bit more to it than just releasing the alphas early - it's about harnessing the power of external deadlines to help counter innate tendencies towards procrastination :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4