Le mardi 15 septembre 2009 à 18:22 -0400, Jesse Noller a écrit :
And I can find at least 176 reasons why owners are a good idea:
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. So much for owners being a good thing.
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. Perhaps it wasn't clear, but I draw a clear separation between exclusive owners and maintainers. 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. Regards Antoine.