On Wed, Jan 28, 2009 at 4:32 AM, Steve Holden <st...@holdenweb.com> wrote: > I think that both 3.0 and 2.6 were rushed releases. 2.6 showed it in the > inclusion (later recognizable as somewhat ill-advised so late in the > day) of multiprocessing; 3.0 shows it in the very fact that this > discussion has become necessary.
What about some kine of mechanism to "triage" 3rd party modules? Something like: module gains popularity -> the core team decides it's worthy -> the module is included in the library in some kind of "contrib"/"ext" package (like the future mechanism) and for one major release stays in that package (so developers don't have to rush fixing _all_ the bugs they can while making a major release) -> after (at least) one major release the module moves up one level and it's considered stable and rock solid. Meanwhile the documentation must say that the 3rd party contributed module is not considered production ready, though usable, until the release current + 1 I don't know if it feasible, if it's insane or what, it's just an idea I had. -- Lawrence, http://oluyede.org - http://twitter.com/lawrenceoluyede "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
