<br><br><div><span class="gmail_quote">On 3/5/07, <b class="gmail_sendername">A.M. Kuchling</b> &lt;<a href="mailto:amk@amk.ca">amk@amk.ca</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt;From &lt;<a href="http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python">http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python</a>&gt;:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4. The patch mafia. I like everyone on python-dev that I meet,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;but somehow it is annoyingly difficult to get a patch into<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Python. Like threading, and the stdlib, this is a mixed<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;blessing: you certainly don&#39;t want every Joe Schmoe checking<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in whatever crud he wants. However, the barrier is high enough
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;that I no longer have much interest in spending the time to<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;shepherd a patch through. Yes, this is probably all my fault<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- but I still hate it!<br><br>FWIW, I have a related perception that we aren&#39;t getting new core
<br>developers. These two problems are probably related: people don&#39;t get<br>patches processed and don&#39;t become core developers, and we don&#39;t have<br>enough core developers to process patches in a timely way.&nbsp;&nbsp;And so
<br>we&#39;re stuck.<br><br>Any ideas for fixing this problem?</blockquote><div><br>A better patch-tracker, better procedures for reviewing patches surounding this new tracker, one or more proper dvcs&#39;s for people to work off of. I&#39;m not sure about &#39;identifying core developers&#39; as we&#39;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&#39;t find the time to review the patches on subjects I know much about, let alone the rest of the patches.)
<br></div><br>While submitting patches is good, there&#39;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&#39;t think it&#39;s unreasonable to ask for help from the submitters like we do, or ask them to write tests and docs and such.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Tangentially related:<br>At PyCon, there was general agreement that exposing a read-only
<br>Bazaar/Mercurial/git/whatever version of the repository wouldn&#39;t be<br>too much effort, and might make things easier for external people<br>developing patches.&nbsp;&nbsp;Thomas Wouters apparently has private scripts<br>that perform the conversion.&nbsp;&nbsp;What needs to be done to move ahead with
<br>this idea?</blockquote><div><br>I need to get time, or people need to volunteer to do the work :) It&#39;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&#39;m weird/paranoid/fascinated by the potential and the elegance) -- but I doubt I&#39;ll get the time, and the monotone conversion takes many times as long as the rest.
<br><br>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&#39;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&#39;ll see about that when we get there.)
<br></div></div><br>[*]: 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&#39;s not dealing with backports yet :)
<br>-- <br>Thomas Wouters &lt;<a href="mailto:thomas@python.org">thomas@python.org</a>&gt;<br><br>Hi! I&#39;m a .signature virus! copy me into your .signature file to help me spread!