[Python-Dev] Encouraging developers (original) (raw)

Josiah Carlson jcarlson at uci.edu
Tue Mar 6 03:11:43 CET 2007

Giovanni Bajo <rasky at develer.com> wrote:

On 05/03/2007 20.30, Phil Thompson wrote: > 2. Publically identify the core developers and their areas of expertise and > responsibility (ie. which parts of the source tree they "own").

I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires much less knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules.

Sometimes code is correct. Sometimes code is complete. Just because a module hasn't been significantly altered or updated recently doesn't mean that it is outdated or broken. Asyncore, for example, is more or less feature complete for a minimal asynchronous socket framework. Could it gain more features (like good SSL support) or have better error handling? Of course. But it passes the test suite (via test_asynchat), so I would consider it not broken.

My suggestion is:

- keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). - if there's no maintainer for a module, the first volunteer can become so. - any patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) must be applied unless the maintainer objects in X days (if a maintainer exists... otherwise it will just go in).

Just because a patch doesn't break a module, doesn't mean the patch should be applied. Take, for example, any one of the patches currently offered against asyncore. One of them more or less changes the internal structure of the module for no other reason than to (in my opinion) be gratuitous. Certainly it has some good ideas, but it would be better to adapt portions rather than take it completely - which is what you are suggesting, and which is what would have happened due to the absence of an asyncore maintainer (until I took it up).

> 4. Acceptance by core developers that only half the "job" is developing the > core - the other half is mentoring potential future core developers.

Acceptance that any patch is better than no patch. There are many valid Python programmers out there, and there are many many patches to stdlib which really don't even require a good programmer to be written.

Maybe, but there are also many patches I've seen that cause the resulting code to not run, revert changes made to fix bugs, etc. Vetting patches is a pain in the butt, and accepting all patches that aren't objected to is a braindead approach to patching the standard library.

Indeed, every module and package should have a known and documented maintainer, but that's really the only part of your suggestions in the message I'm replying to that I would agree with. The rest gets a -1.

More information about the Python-Dev mailing list