[Python-Dev] Encouraging developers

[Josiah Carlson]

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.


 - Josiah