[stdlib-sig] Breaking out the stdlib

[Jesse Noller]

On Tue, Sep 15, 2009 at 6:52 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le mardi 15 septembre 2009 à 18:22 -0400, Jesse Noller a écrit :

> Sorry, what's that URL supposed to prove? What does it even represent?
> It is a populist argument at best, because I won't skim through those
> 176 bugs to try and make sense of your argument. If you want to make a
> point, please don't try to leave the burden of proof on me.
>
> Actually, I'll just take one of them, because I know it quite well:
> http://bugs.python.org/issue4967
>
> This is a bug in _ssl for which I had to write a patch, although I knew
> nothing about _ssl, because the owner wouldn't react. He wouldn't react
> for review either. The bug *had* to be fixed because it blocked the
> whole process of including the C IO library.
> Finally, Benjamin committed the patch. The owner didn't give a sign of
> life *during the whole process*. He isn't dead, he still sometimes
> contributes to python-dev, but he was totally unavailable when his
> presence was needed.

And there are over 176 bugs with patches, and more needing patches
which could use patches, docs, or tests. I guess that makes all of us
negligent and bad maintainers.

> So much for owners being a good thing.

So much for bad owners. Owners, by the very definition, must be
active, and responsive (even if it's not real-time). People who are
domain experts, but who are largely MIA are not a benefit.

>> The fact is, we need people who feel responsibility for every one of
>> these modules to review patches, and have some amount of mental design
>> integrity to ensure modules don't just wander off into the sunset and
>> die.
>
> But this is not the same as having an owner.

yes it is, but I think we're arguing the semantics of the word "owner"
- how about "person on the hook"

> Perhaps it wasn't clear, but I draw a clear separation between exclusive
> owners and maintainers.

Maybe we can agree on "maintainer" than "owner" - I did not mean
exclusive ownership, and I apologize if I gave that impression.

> 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).

If I did that, I'd go insane.

> 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.

Agreed.

> 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.

Agreed; but the maintainer should at least have a chance to say
something, or be +noisy on issues at very least. I completely agree
code dictatorship is bad, and I've seen it harm open source, and
business code bases *a lot*.

jesse