[stdlib-sig] Breaking out the stdlib

[M.-A. Lemburg]

Antoine Pitrou wrote:
> I'm all for non-exclusive maintainership, with people having reasonable
> authority over code they understand thoroughly. You taking care of
> multiprocessing falls into this category (as long as you don't demand to
> approve of all changes before they are committed).
> 
> I'm against ownership, however. I'm against mandatory signoffs
> (imprimaturs), and I'm against the possessive sentiment that some might
> develop towards a piece of code they contributed. Any core developer
> should be allowed to commit a patch if he thinks the patch is reasonable
> enough and serves an useful purpose.
> 
> Ownership prevents proper maintenance when the owner is absent (which
> *will* happen, since we are all unpaid volunteers). It discourages other
> people from getting acquainted with the code, which gradually makes the
> problem worse. Furthermore, it is often correlated with strange
> (personal) idioms, coding styles and design principles.

I don't see things as negative as you apparently do.

Owning a piece usually means that you wrote it and have good reasons
for the design and code being what it is. It's a matter of respect
towards the author to ask for review and discussion of a patch
or new idea.

If maintenance is passed on to someone else, the maintainer
becomes the authority to discuss a patch with.

If a maintainer or owner doesn't respond within 2-3 weeks
(yes, people do go on vacation sometimes ;-), then I think
it's ok to get review of the patch by some other core developer
and then check it in - the maintainer or owner can always go
back and revert the patch, if it doesn't fit for some reason.

If this happens for longer periods of time, the maintainer
or owner should be asked to pass on maintenance to someone
else.

Now, what to do in case of conflicts ? I.e. a core developer
wants to add some new feature, change the design, etc. and
the maintainer or owner disagrees.

Well, we do what we've always done in the past: discuss the
proposed changes on python-dev. If things go well, a compromise
is found, otherwise the BDFL decides as tie-breaker.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 16 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/