On 3/5/07, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>From <http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python >: 4. The patch mafia. I like everyone on python-dev that I meet, but somehow it is annoyingly difficult to get a patch into Python. Like threading, and the stdlib, this is a mixed blessing: you certainly don't want every Joe Schmoe checking in whatever crud he wants. However, the barrier is high enough that I no longer have much interest in spending the time to shepherd a patch through. Yes, this is probably all my fault -- but I still hate it! FWIW, I have a related perception that we aren't getting new core developers. These two problems are probably related: people don't get patches processed and don't become core developers, and we don't have enough core developers to process patches in a timely way. And so we're stuck. Any ideas for fixing this problem?
A better patch-tracker, better procedures for reviewing patches surounding this new tracker, one or more proper dvcs's for people to work off of. I'm not sure about 'identifying core developers' as we're all volunteers, with dayjobs for the most part, and only a few people seem to care enough about python as a whole. Putting the burden of patch review on the developers that say they can cover it might easily burn them out. (I see Martin handle a lot of patches, for instance, and I would love to help him, but I just can't find the time to review the patches on subjects I know much about, let alone the rest of the patches.) While submitting patches is good, there's a lot more to it than just submitting the 5-line code change to submit a bug/feature, and reviewing takes a lot of time and effort. I don't think it's unreasonable to ask for help from the submitters like we do, or ask them to write tests and docs and such. Tangentially related:
At PyCon, there was general agreement that exposing a read-only Bazaar/Mercurial/git/whatever version of the repository wouldn't be too much effort, and might make things easier for external people developing patches. Thomas Wouters apparently has private scripts that perform the conversion. What needs to be done to move ahead with this idea?
I need to get time, or people need to volunteer to do the work :) It's not entirely easy to do, depending on the dvcs in question. Canonical will be getting us an up to date conversion to Bazaar in a couple of weeks or so; I will be using that, or a Mercurial conversion I do myself, to refactor all Py3K work into separate branches for easier[*] backporting. I would love to do one for Monotone too (my personal favourite, but I'm weird/paranoid/fascinated by the potential and the elegance) -- but I doubt I'll get the time, and the monotone conversion takes many times as long as the rest. Of course, anything I set up for py3k will be accessible by anyone, and it would include a straight conversion from the trunk, too. And for those developers that worry about having to switch (or others having to switch) from svn to something confusing: we'll keep the p3yk branch intact (possibly after a rebuild) for people to keep submitting patches against. (I could even grab commits from the svn branch and stuff them into a bzr/hg branch, but we'll see about that when we get there.) [*]: by easier, I mean simple, straightforward, explainable, reproducible and scalable, rather than a godawful pigfucking lot of work that will undoubedly get messy bugs crept in. I doubt I did all the py3k merges properly as-is, and that's not dealing with backports yet :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ 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
