dustin> In summary, create a layer of volunteer, non-committing
dustin> maintainers for specific modules who agree to do in-depth
dustin> analysis of patches for their areas of expertise, and pass
dustin> well-formed, reviewed patches along to committers.
One problem with this sort of system is that it's difficult for many people
to commit the personal resources necessary over a long period of time. Life
often gets in the way. Consider the rather simple task of fielding
submissions to the Python job board. I think three or four different people
who have taken care of that task over the last two or three years. In each
case the transition to a new person was a bit bumpy because life sort of
jumped up an bit the current maintainer in the butt, leaving a scramble to
find a new person to take over that role.
Now consider how simple that is compared with, say, being the Python XML
guru. Let's say Fred Drake takes on that role. (I'm not picking on Fred.
My brain just associates him with XML-in-Python, rightly or wrongly.) Things
go swimmingly for awhile, then he gets a huge load dumped on him at work,
his wife has a baby and the family moves to Austin, TX to be close to his
aging parents. After moving to Austin it takes a month to get a properly
functioning Internet connection because the phone company is so lame. I
think it's understandable that his level of committment to XML-in-Python
might be reduced. Other events in his life might take over to such an
extent that he forgets to (or can't easily) let anyone know. It's not until
someone happens to notice (maybe Fred, maybe Martin, maybe nobody for quite
awhile) that there are a bunch of XML-related bug reports and patches piling
up that the team starts looking for someone new to assume that role.
Skip
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
