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/ _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
