> [Fred L. Drake, Jr.] > > ... > > Managing the bugfix releases would also be an excellent task for > > someone who's expecting to use the bugfix releases more than the > > feature releases -- the mentality has to be right for the task. I > > know I'm much more of a "features" person, and would have a hard time > > not crossing the line if it were up to me what went into a bugfix > > release. [Uncle Timmy] > Note there was never a bugfix release for 1.5.2, despite that 1.5.2 had some > serious bugs, and that 1.5.2 was current for an unprecedentedly long time. > Guido put out a call for volunteers to produce a 1.5.2 bugfix release, but > nobody responded. Past is prelude ... > > everyone-is-generous-with-everyone-else's-time-ly y'rs - tim I understand the warning. How about the following (and then I really have to go write my keynote speech :-). PythonLabs will make sure that it will happen. But how much stuff goes into the bugfix release is up to the community. We'll give SourceForge commit privileges to individuals who want to do serious work on the bugfix branch -- but before you get commit privileges, you must first show that you know what you are doing by submitting useful patches through the SourceForge patch mananger. Since a lot of the 2.0.1 effort will be deciding which code from 2.1 to merge back into 2.0.1, it may not make sense to upload context diffs to SourceForge. Instead, we'll accept reasoned instructions for specific patches to be merged back. Instructions like "cvs update -j<rev1> -j<rev2> <file>" are very helpful; please also explain why! --Guido van Rossum (home page: http://www.python.org/~guido/)
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