On Tue, Sep 15, 2009 at 6:52 PM, Antoine Pitrou <solip...@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 _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
