Re: [Python-Dev] Encouraging developers
On 18/03/07, Tony Meyer [EMAIL PROTECTED] wrote: on someone else's patch. It seems relevant to me that the original poster (Tony Meyer) hasn't felt strongly enough to respond on his own behalf to comments on his patch. No disrespect to Tony, but I'd argue that the implication is that the patch should be rejected because even the submitter doesn't care enough to respond to comments! There is a considerable difference between doesn't care enough, and has not had time to be able to (although in this specific case doesn't care enough is correct). On rereading my comments, I apologise - you're absolutely right that I didn't have enough evidence to judge that you don't care enough about the patch. Thanks for clarifying - I entirely agree with you that just being willing to put together any sort of bug report or patch is valuable, and people should not be discouraged from doing so. (It's a sad but probably inevitable fact that many such contributors - I include myself here! - have expectations of speed of response which simply aren't possible for a volunteer project, and as a result get frustrated with the process, but that's a separate issue) Paul. ___ 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
Re: [Python-Dev] Encouraging developers
Tony Meyer schrieb: ISTM that there is value in submitting a patch (including tests and documentation, and making appropriate comment in related patches), even if that is all that is done (i.e. no follow-up). That's certainly, absolutely, true. It's also true that there are very many kinds of different contributions, e.g. a bug report is a contribution, too. However, some contributions bring the project forward more than others, e.g. a patch often brings it further along than a bug report, and a patch contributor willing to rework the patch brings it further along than a contributor that just drops the patch into the tracker (after developing it first, of course). Given that we are not able to process all contributions, we clearly have to make choices what contributions to look at, and what contributions to ignore. This, unfortunately, means that some patches get rejected just because neither the submitter nor any of the reviewers is willing to complete it, if it is incomplete at the time of submission. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
On 8/03/2007, at 2:42 AM, Paul Moore wrote: On 06/03/07, Scott Dial [EMAIL PROTECTED] wrote: Sadly the sf tracker doesn't let you search for With comments by. The patch I was making reference to was 1410680. Someone else actually had wrote a patch that contained bugs and I corrected them. And with that, I was the last person to comment or review the patch in question. [...] On the other hand, what I've done is similar to what you did - comment on someone else's patch. It seems relevant to me that the original poster (Tony Meyer) hasn't felt strongly enough to respond on his own behalf to comments on his patch. No disrespect to Tony, but I'd argue that the implication is that the patch should be rejected because even the submitter doesn't care enough to respond to comments! There is a considerable difference between doesn't care enough, and has not had time to be able to (although in this specific case doesn't care enough is correct). I have submitted a very small (3?) number of patches, however, I suspect that my position is similar to others, so I offer an explanation in the hope that it adds value to this thread. I don't submit patches because I need the problem fixed in the Python distribution. I make the change locally, and either I am distributing a frozen application (almost always the case), which includes my local fix, or a workaround is made in the application source which means that the main Python distribution fix is unneeded (e.g. this is what I did with SpamBayes). The particular patch mentioned is one that uses code (more-or-less) from SpamBayes. SpamBayes has the code - it doesn't matter whether it's in the Python distribution or not. At the time I wrote the patch, there were (again) discussions on python-dev about what should be done to ConfigParser. I had some time free in those days, and, since I had some code that did more-or-less what Guido indicated was the best option, I contributed it (writing unittests, documentation, and commenting in the related tickets). To a certain extent, I considered that my work done. This was something I contributed because many people continually requested it, not something I felt a personal need to be added to the distribution (as above, that's not a need that I generally feel). I (much) later got email with patches, and then later email from Mark Hammond about the patch (IIRC Mark was looking at it and was thinking of fixing it up; I think I forwarded the email I got to him. OTOH, maybe he also sent me fixes - I'm too busy to trawl through email archives to figure it out). At the time, I hoped to fix up the errors and submit a revised patch, but my son was born a few weeks later and I never found the time. If the patch had been reviewed more quickly, then I probably would have found time to correct it - however, everyone else is busy to (if I felt strongly about it, then I would have reviewed 5 other patches, as I have in the past, and 'forced' more quick review, but I did not). For me, submitting a patch is mostly altruistic - if I do that then other people don't also have do the work I did, and hopefully other people do that as well, saving me work. It's not something I require, at all. This isn't something that is easy to make time for. ISTM that there is value in submitting a patch (including tests and documentation, and making appropriate comment in related patches), even if that is all that is done (i.e. no follow-up). If the value isn't there without that follow-up 'caring', then that is something that should be addressed to 'encourage developers'. Contributions don't only come from people hoping to be 'core' developers some day. Uncaringly-(with-apologies-to-uncle-timmy), Tony ___ 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
Re: [Python-Dev] Encouraging developers
On Fri, Mar 09, 2007 at 10:10:48PM -0800, Neal Norwitz wrote: We should probably be a lot more aggressive about closing bugs and patches without response. Unfortunately many fall into this category. This question comes up every so often, and after much discussion I think python-dev always converges on leaving bugs open in case some future person finds the information useful. I hope that the Roundup tracker will let us tag such bugs with a 'waiting-for-reporter' tag, and we can then exclude such bugs when looking for ones to fix. --amk ___ 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
Re: [Python-Dev] Encouraging developers
On 3/10/07, A.M. Kuchling [EMAIL PROTECTED] wrote: On Fri, Mar 09, 2007 at 10:10:48PM -0800, Neal Norwitz wrote: We should probably be a lot more aggressive about closing bugs and patches without response. Unfortunately many fall into this category. This question comes up every so often, and after much discussion I think python-dev always converges on leaving bugs open in case some future person finds the information useful. I was thinking about patches only in this case, not bugs. I hope that the Roundup tracker will let us tag such bugs with a 'waiting-for-reporter' tag, and we can then exclude such bugs when looking for ones to fix. Georg added a comment/feature request for this. Actually, he requested a close on inactivity after some duration if we set a keyword or something like that. Since we are in control of the tracker, we can make it happen if someone cares enough. n ___ 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
Re: [Python-Dev] Encouraging developers
On 3/7/07, Facundo Batista [EMAIL PROTECTED] wrote: A.M. Kuchling wrote: 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? I think that there's a barrier entry: there's no place to ask for help on silly problems when you're trying to help (!). Let me explain my bad english wording, with an example. Yesterday night I started modifying socket.py and test_socket.py. Of course, I said, let's see if the tests pass ok *before* start changing anything. Went to ~/devel/reps/python/trunk/Lib, and made: $ python2.5 test/test_socket.py... Wrong! Damn! Tried a lot of stuff... $ cd test $ python2.5 test_socket.py... Wrong! $ python2.5 regrtest.py test_socket ... Wrong! $ python2.5 regrtest.py test_socket.py ... Wrong! $ python2.5 regrtest.py socket ... Wrong! And thousand more combinations. The best I could do is actually execute the tests, but python was getting the installed socket module, and not the repository socket module (even that I was in the same directory of the latter). I didn't know what to try. I was stuck. This never happened to me when working on Decimal. What went wrong in my head in the middle? I finally understood the problem, and build python from the repository, and made the tests from *this* python (actually, this was an easy step because I'm on Ubuntu, but *I* would be dead if working in Windows, for example). Ok. *Me*, that I'm not ashame of asking what I don't know, if I didn't resolve it I'd finally asked in python-dev. But how many people would have throw the towel withoug getting so far? How many people want to submit a patch, or even a bug, or finds a patch to review, but don't know how to do something and thinks that python-dev is not the place to ask (too high minds and experienced people and everything)? What I propose is a dedicated place (mailing list, for example), that is something like a place where you can go and ask the silliest questions about helping in the developing process. - How can I know if a patch is still open? - I found a problem, and know how to fix it, but what else need to do? - Found a problem in the docs, for this I must submit a patch or tell something about it? How? - I found an error in the docs, and fixed it, but I'm spanish speaker and my english sucks, can I submit a patch with bad wording or I must ask somebody to write it ok? Me, for example, has an actual question to this list: How can I know, if I change something in the doc's .tex files, that I'm not broking the TeX document structure?. I think this was answered in a separate thread, but I want to make sure everyone sees it here. In addition to the buildbots that run on every checkin (more or less), Misc/build.sh runs every 12 hours. This script does a full build, make install, runs the regression test suite *with refleak checking*, and builds the docs. Any errors are sent to python-checkins. The results from building the docs are here: http://docs.python.org/dev/ - for the trunk (ie, currently 2.6) http://docs.python.org/dev/2.5/ The results from running Misc/build.sh are found by adding results/ to either of the URLs above. If the doc doesn't build, the development versions of the doc are not overwritten. So to answer your question, you will know if you break a test or documentation by following python-checkins. Here is an example of when a refleak was detected: http://mail.python.org/pipermail/python-checkins/2007-February/058689.html Here's an example of when there was a doc failure: http://mail.python.org/pipermail/python-checkins/2006-February/049409.html I've tried to make it hard to screw up Python and not notice. The easiest way to do it now is to check in something without a test. If everything is checked in with a test, it will be very hard to screw something up and for it to not be noticed by some automated system. It would also be nice to run texcheck.py in build.sh to catch things like unbalanced parens. n ___ 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
Re: [Python-Dev] Encouraging developers
On 3/5/07, Scott Dial [EMAIL PROTECTED] wrote: If nothing else, as an outsider there is no way to know why your patch gets ignored while others get swiftly dealt with. Any sort of information like this would at least provide more transparency in what may appear to be elitest processes. Have you read the developer FAQ? http://www.python.org/dev/faq/ If we answered your questions in the FAQ, would that help? Can you come up with a list of questions that the FAQ doesn't address? If you haven't read the FAQ or didn't know it existed, where would you look for answers? Where can we make this info available? I don't believe there is anything elitist about it. I can see how one could get many opinions given that it's opaque from the outside. It's been described, but I'll re-iterate. It's completely up to the reviewers. There are only about a handful of people that I know of that review patches. I was one of those people up until about 2 months ago when I got just too much mail and have to archive most of the patches mail I get. I also look through the bugs pretty regularly to see if there are any very serious or very easy bugs to fix. When I reviewed patches, I would only look at ones I thought I could address in however much time I had and felt qualified to apply. If I don't know enough about a subject area, I typically don't look. I can't tell if a swizzle method would really be appropriate for a boombah since I didn't even know python had a boombah. Sometimes I comment on patches and don't get a response. We should probably be a lot more aggressive about closing bugs and patches without response. Unfortunately many fall into this category. Other bugs/patches go something like this: the documentation could be clearer. If I understand the current doc, there's no hope of me making it clearer. More guidance by others who might be able to provide concrete options (e.g. specific wording), can allow us to make a decision. n ___ 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
Re: [Python-Dev] Encouraging developers
Josiah Carlson writes: And the best way to encourage someone to maintain a package is... accepting their patches. And that's what I think is bull. Whether or not we want or need maintainers for module or package X is independant of the fact that user Y has submitted a patch for it. If they say, I would like to become maintainer of package X, ok, if they are better than not having a maintainer, great. But to ask them to be a maintainer of an unmaintained package because they submitted a patch? Actually, I regularly do this (three or four times a year, I'd guess, it would be more if there were more submitters) if the person seems sane. But I *don't* apply the patch! The condition is that he sign on to our process and shepherd his own patch through it (including the risk that a reviewer will ask for changes). The answer I typically get is No, I'd rather wait than work. But thanks for asking! :-) Caveat: the XEmacs packages where I do this are mostly end-user applications like MUAs or programmer editor modes, so it doesn't matter to anyone but the end-users if they break. Our process provides multiple workarounds for such a situation, and we do keep an eye on new maintainers to help out with emergency response in those cases, so that risk is considered acceptable. The users themselves generally accept one or two new maintainer problems with good humor, since they're proof positive that somebody has taken an interest in their package. The cost to this system is that you need people willing to mentor the new package maintainers. It works well for XEmacs because the cost is very low (as I just described). I think for Python's stdlib the cost would be substantially higher, but it might very well be worth it. A little game: without looking at this patch of mine, how much are you willing to bet that committing that patch is going to cause pain the Python community and other stdlib maintainers, to cause headaches like deprecations because of broken interfaces, and whatnot? I'm glad you asked. More than half of my commits (and way more than half the LOC) in February were due to broken previous patches that were approved merely because they addressed a bug and applied without fuzz to HEAD. :-( Committing patches unreviewed is a terrible idea. ___ 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
Re: [Python-Dev] Encouraging developers
Giovanni Bajo schrieb: I can't see that the barrier at contributing is high. I think this says it all. It now appears obvious to me that people inside the mafia don't even realize there is one. Thus, it looks like we are all wasting time in this thread, since they think there is nothing to be changed. But I am blaming you because you don't admit the fact that there *is* a problem with the patch submission process. And we can't a solve a problem if we don't admit there is one in the first place. I do think there is a problem with patch processing - I just don't think the barrier at contributing is high. The fact that there are so many patches contributed is proof that the barrier is not high: many people feel they can submit a patch. You might be right, there's no way to really know of course. I think my patch is a good example of how my proposal can be good for the Python stdlib. My proposal (to recall) is to *automatically* apply any patch to stdlib which follows normal guidelines if the package has no maintainer and nobody objects in X days. While it would have worked in your case (although I still wonder who the automatic application of the patch should execute), please be ensured that this couldn't possibly work in general. Many patches are really really not acceptable in their initial form; for many of them, the biggest problem is that they lack documentation. There was a phase when patches got accepted with no documentation, for these modules, it was very difficult to come up with documentation in the following years. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
On 08/03/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Titus Brown schrieb: and it's not at all clear to outsiders like me how new features, old patches, and old bugs are dealt with. The simple answer is when we have time. There really is not more to it. Some patches get higher attention, e.g. because they fix serious bugs. Proposed new features of don't get any attention by the mafia, because Python will just work fine without the new feature. Just to elaborate a bit on Martin's comment. I (very occasionally) scan SF and review patches - I have no commit privilege, so that's all I can do. I find that having enough time is amazingly infrequent. Often, I start looking with all the best intentions, and get bogged down on one item, then find that real life has caught up and I've done what feels like nothing. As regards prioritisation, I don't know of any way of realistically doing this. All I do is scan the list (either from oldest to newest or vice versa depending on my mood) and look for interesting or important looking subjects. I suppose that emphasizes the need for using good subject lines, but not much else :-) As you can see, it's anything but scientific - and there's a lot of ways that important items could get missed. But it's not that way because I'm slacking, or snubbing particular areas or authors - it's just the best way I can find. If anyone can find a better way (and write it up as How to do bug/patch reviews and triage or something) that would be brilliant. I suspect there isn't one, though - at least with SF (Roundup may be better) and given the time and resources I have available. Paul. ___ 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis wrote: - How can I know if a patch is still open? Easy: if it's marked as Open. - I found a problem, and know how to fix it, but what else need to do? Go to www.python.org, then CORE DEVELOPMENT, then Patch submission. - Found a problem in the docs, for this I must submit a patch or tell something about it? How? Read CORE DEVELOPMENT, Intro to development. - I found an error in the docs, and fixed it, but I'm spanish speaker and my english sucks, can I submit a patch with bad wording or I must ask somebody to write it ok? What would your intuition tell you to do? Really didn't the answers to this, just were examples of questions that people may need to do, and feel shy to do it in python-dev... Ok, but I know now that python-dev *is* the place to ask. It's important, to redirect new possible developers and people willing to help. patch, and perhaps the reviewer will catch the error. As a submitter, just submit the code, and George Yoshida will catch it. It's not strictly necessary that the documentation actually builds all the time. If you want to be sure it builds, run make html in Doc. Didn't know about the make html, :) Thanks! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
Re: [Python-Dev] Encouraging developers
Barry Warsaw schrieb: Jira had a way of automatically assigning certain categories to certain people. I think the term was project leader or some such. Of course, this didn't mean that someone else couldn't fix the bug or that the bug couldn't be reassigned to someone else, but at least it initially gives all issues to the person nominally responsible for it. The SF tracker has this also. I'm auto-assigned for Tkinter bugs, for example - not that I review them in a timely manner. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Ron Adam schrieb: But the tracker needs to be able to actually track the status of individual items for this to work. Currently there's this huge list and you have to either wade though it to find out the status of each item, or depend on someone bring it to your attention. Well, the tracker does have a status for each individual report: open or closed. open means needs more work, closed means no more work needed. So don't wade through a report - just assume that if it is open, it needs work. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Giovanni Bajo schrieb: On 06/03/2007 10.52, Martin v. Löwis wrote: I can't see that the barrier at contributing is high. I think this says it all. It now appears obvious to me that people inside the mafia don't even realize there is one. Thus, it looks like we are all wasting time in this thread, since they think there is nothing to be changed. I can feel your pain that your (only) patch was unreviewed for three years. If it makes you happy to blame somebody feel free to, but I feel it is unfair to blame the single person that eventually *did* review and commit your patch. You may ask yourself why this specific patch was unreviewed for so long. My own explanation is that it is a highly complicated algorithm (as any kind of cryptographical algorithm), so nobody felt qualified to review it. I'm pretty sure it was *looked at* often (contrary to your remark in [1]), but none of the people reading it were qualified to comment. So if you want to work on encryption still, please go ahead. Regards, Martin [1] http://mail.python.org/pipermail/python-list/2004-November/293510.html ___ 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
Re: [Python-Dev] Encouraging developers
As an outsider who has submitted a handful of patches and has always wanted to become more involved.. I would like to comment as I feel like I am the target audience in question. I apologize ahead of time if I am speaking out of place. Martin v. Löwis wrote: Phil Thompson schrieb: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. People don't *have* to review patches. They just can do that if they want expedite review of their code. While I understand that this tit-for-tat mechanism is meant to ensure participation, I believe in reality it doesn't, as the 400-some outstanding patches you referenced elswhere indicate. I can personally attest to having a patch that is over a year old with no core developer having any interest at all with the subject matter. And to be frank, nor did I really, but I saw a problem and was capable of solving it. My lack of caring about the patch means I am not going to beat people over the head to pay attention. This system is broken for someone like me (coder) that just wants to help out (non-coders). 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I doubt this will help. Much of the code isn't owned by anybody specifically. Those parts that are owned typically find their patches reviewed and committed quickly (e.g. the tar file module, maintained by Lars Gustäbel). If nothing else, as an outsider there is no way to know why your patch gets ignored while others get swiftly dealt with. Any sort of information like this would at least provide more transparency in what may appear to be elitest processes. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis wrote: Paul Moore schrieb: Here's a random offer - let me know the patch number for your patch, and I'll review it. Surprisingly (and I hope Scott can clarify that), I can't find anything. Assuming Scott's SF account is geekmug, I don't see any open patches (1574068 was closed within 20 days by amk, last October). Sadly the sf tracker doesn't let you search for With comments by. The patch I was making reference to was 1410680. Someone else actually had wrote a patch that contained bugs and I corrected them. And with that, I was the last person to comment or review the patch in question. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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
Re: [Python-Dev] Encouraging developers
A.M. Kuchling wrote: 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? I think that there's a barrier entry: there's no place to ask for help on silly problems when you're trying to help (!). Let me explain my bad english wording, with an example. Yesterday night I started modifying socket.py and test_socket.py. Of course, I said, let's see if the tests pass ok *before* start changing anything. Went to ~/devel/reps/python/trunk/Lib, and made: $ python2.5 test/test_socket.py... Wrong! Damn! Tried a lot of stuff... $ cd test $ python2.5 test_socket.py... Wrong! $ python2.5 regrtest.py test_socket ... Wrong! $ python2.5 regrtest.py test_socket.py ... Wrong! $ python2.5 regrtest.py socket ... Wrong! And thousand more combinations. The best I could do is actually execute the tests, but python was getting the installed socket module, and not the repository socket module (even that I was in the same directory of the latter). I didn't know what to try. I was stuck. This never happened to me when working on Decimal. What went wrong in my head in the middle? I finally understood the problem, and build python from the repository, and made the tests from *this* python (actually, this was an easy step because I'm on Ubuntu, but *I* would be dead if working in Windows, for example). Ok. *Me*, that I'm not ashame of asking what I don't know, if I didn't resolve it I'd finally asked in python-dev. But how many people would have throw the towel withoug getting so far? How many people want to submit a patch, or even a bug, or finds a patch to review, but don't know how to do something and thinks that python-dev is not the place to ask (too high minds and experienced people and everything)? What I propose is a dedicated place (mailing list, for example), that is something like a place where you can go and ask the silliest questions about helping in the developing process. - How can I know if a patch is still open? - I found a problem, and know how to fix it, but what else need to do? - Found a problem in the docs, for this I must submit a patch or tell something about it? How? - I found an error in the docs, and fixed it, but I'm spanish speaker and my english sucks, can I submit a patch with bad wording or I must ask somebody to write it ok? Me, for example, has an actual question to this list: How can I know, if I change something in the doc's .tex files, that I'm not broking the TeX document structure?. Just my two argentinian cents. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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
Re: [Python-Dev] Encouraging developers
On 06/03/07, Scott Dial [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: Paul Moore schrieb: Here's a random offer - let me know the patch number for your patch, and I'll review it. Surprisingly (and I hope Scott can clarify that), I can't find anything. Assuming Scott's SF account is geekmug, I don't see any open patches (1574068 was closed within 20 days by amk, last October). Sadly the sf tracker doesn't let you search for With comments by. The patch I was making reference to was 1410680. Someone else actually had wrote a patch that contained bugs and I corrected them. And with that, I was the last person to comment or review the patch in question. OK, as promised, I've reviewed it. I've recommended some actions from the original poster, or if they aren't forthcoming, then rejection. If you (Scott) want to pick this up, I'd recommend: 1. Open a new patch, with your recommended changes. 2. Address the comments made against Tony's patch, in yours. 3. Add a recommendation to Tony's patch that it be closed in favour of yours. Wait and/or canvas further opinion. That's about all I can do - to get the code *into* Python (if it's appropriate - remember that I've recommended rejection!) then you need someone with commit privileges to apply it. On the other hand, what I've done is similar to what you did - comment on someone else's patch. It seems relevant to me that the original poster (Tony Meyer) hasn't felt strongly enough to respond on his own behalf to comments on his patch. No disrespect to Tony, but I'd argue that the implication is that the patch should be rejected because even the submitter doesn't care enough to respond to comments! Paul. ___ 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
Re: [Python-Dev] Encouraging developers
Facundo Batista schrieb: How many people want to submit a patch, or even a bug, or finds a patch to review, but don't know how to do something and thinks that python-dev is not the place to ask (too high minds and experienced people and everything)? What I propose is a dedicated place (mailing list, for example), that is something like a place where you can go and ask the silliest questions about helping in the developing process. In my experience, direct communication, e.g. via IRC channels, is much less intimidating for newcomers than a publicly read and archived mailing list. That said, I'm in #python-dev on Freenode most of the time and I'd be happy to help out new developers (as soon as the questions are still so simple for me to answer ;). Of course, the channel would have to be made an official Python development tool and advertised on e.g. the website. Also, it couldn't hurt if some of the other devs would frequent it too, then :) Georg ___ 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
Re: [Python-Dev] Encouraging developers
Paul Moore schrieb: 1. Open a new patch, with your recommended changes. I'd like to second this. If you are creating a patch by responding in a comment, it likely gets ignored. 2. Address the comments made against Tony's patch, in yours. 3. Add a recommendation to Tony's patch that it be closed in favour of yours. This also sounds good. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis wrote: Ron Adam schrieb: But the tracker needs to be able to actually track the status of individual items for this to work. Currently there's this huge list and you have to either wade though it to find out the status of each item, or depend on someone bring it to your attention. Well, the tracker does have a status for each individual report: open or closed. open means needs more work, closed means no more work needed. So don't wade through a report - just assume that if it is open, it needs work. Regards, Martin I should have said... ... the status of individual items *in more detail* for this to work *well*. Sorry, Ron ___ 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] You may ask yourself why this specific patch was unreviewed for so long. My own explanation is that it is a highly complicated algorithm (as any kind of cryptographical algorithm), so nobody felt qualified to review it. I'm pretty sure it was *looked at* often (contrary to your remark in [1]), but none of the people reading it were qualified to comment. I have looked at nunerous patches without commenting because I could not or did not do a full review. You and Neal have convinced me that I have been too shy and that even little comments like 'the doc revision looks good' might help. tjr ___ 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
Re: [Python-Dev] Encouraging developers
Giovanni Bajo [EMAIL PROTECTED] wrote: On 3/6/2007 3:11 AM, Josiah Carlson wrote: Giovanni Bajo [EMAIL PROTECTED] wrote: I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. Sometimes code is correct. Sometimes code is complete. Just because a module hasn't been significantly altered or updated recently doesn't mean that it is outdated or broken. You can't decide this unless you are a maintainer of that module. If a programmer felt the urge to pack up a patch and submit it to SF.NET, he probably has an idea. It might be a good idea. It might not be the best, but at least it's an idea. It might even be just a bugfix. If you see the patch, know the module well, and can express a judgement, you just need to review it and discuss it. But I really can't see what's *worse* than getting a patch unreviewed and unapplied. And who is advocating for patches to be unreviewed and unapplied? I'm not. If *anyone* is advocating such a position, then I claim that they are idiots. Asyncore, for example, is more or less feature complete for a minimal asynchronous socket framework. Could it gain more features (like good SSL support) or have better error handling? Of course. But it passes the test suite (via test_asynchat), so I would consider it *not* broken. Because you are the maintainer and you know well. I used asyncore once, and I felt it was incomplete. So I went looking for something else. That's fine. You probably know asyncore very well, so your judgement is important and you'll be reviewing the patches and vetoing them if you don't like. I'll tell you the biggest problem with asyncore: there are few *good* samples of asyncore usage in the wild, and there isn't even one really in the standard library (smtpd does OK, but it could be better). The asynchat module is supposed to add *just enough* functionality to get people started, but its lack of a sample collect_incoming_data() and found_terminator() that generally do the right thing, are sticking points for many people. Among the changes I'm going to be pushing for is the inclusion of sample implementations of those two methods in asynchat (as well as a fix for when a string terminator is longer than ac_in_buffer_size). If asynchat had them in the summer of 2001, I probably wouldn't have more or less reimplemented my own asynchronous sockets framework that summer and fall 3 different times. But there are modules without maintainers. We agree that every module should have a maintainer, and that's fine. But you seem to ignore the fact that we ought to find a solution for modules and packages without maintainers. What is your proposed solution, once if we agree that the current state of affairs suck? You can't force people to step up for maintainership of course, so you have to find something in the middle. And the best way to encourage someone to maintain a package is... accepting their patches. And that's what I think is bull. Whether or not we want or need maintainers for module or package X is independant of the fact that user Y has submitted a patch for it. If they say, I would like to become maintainer of package X, ok, if they are better than not having a maintainer, great. But to ask them to be a maintainer of an unmaintained package because they submitted a patch? That's a bit like inviting everyone who has ever programmed to be an IEEE or ACM fellow. That's nice and inclusive, but not the way you gather together people who can and will develop quality code. Just because a patch doesn't break a module, doesn't mean the patch should be applied. Take, for example, any one of the patches currently offered against asyncore. One of them more or less changes the internal structure of the module for no other reason than to (in my opinion) be gratuitous. Certainly it has some good ideas, but it would be better to adapt portions rather than take it completely - which is what you are suggesting, and which is what would have happened due to the absence of an asyncore maintainer (until I took it up). Engineering is a matter of tastes and opinions, more often than not. Once you are a maintainer, your taste wins. But if there are no maintainers, I prefer to trust someone who wasted his time to produce a patch, rather than just blatantly ignore his job. At least, he had an urge and produced some code. He did put forward his opinion. Certainly opinions differ, which is what this is. However, even high-quality patches (like the one produced by Larry Hastings for string concatenation and views) are rejected because the functionality
Re: [Python-Dev] Encouraging developers
On Wed, Mar 07, 2007 at 11:10:22AM +0100, Martin v. L?wis wrote: - Giovanni Bajo schrieb: - On 06/03/2007 10.52, Martin v. L?wis wrote: - - I can't see that the barrier at contributing is high. - - I think this says it all. It now appears obvious to me that people - inside the mafia don't even realize there is one. Thus, it looks like - we are all wasting time in this thread, since they think there is - nothing to be changed. delurk Hi, I just wanted to interject -- when I used the word mafia, I meant it in this sense: Informal. A tightly knit group of trusted associates, as of a political leader: [He] is one of the personal mafia that [the chancellor] brought with him to Bonn. (Martin, I certainly didn't intend to offend anyone by implying that they were part of a criminal organization. ;) I have a longer explanation of my view in the blog entry, and anyway I don't want to belabor my own experiences too much, but I would like to point out three things: * there's definitely a group of trusted associates -- committers, perhaps? -- and it's not at all clear to outsiders like me how new features, old patches, and old bugs are dealt with. * python-dev is an all-volunteer community. In true open-source fashion, that means that it's incumbent upon people who HAVE problems/issues with a process (like me, and Giovanni) to propose solutions that either someone wants to implement, or that we can implement. I certainly don't expect any of the committers to put tons of effort into a new initiative. * Much of the discussion on this issue of encouraging developers comes down to communicating better with non-python-dev people. Unless someone is already doing it, I will try to write a summary of the last few days of discussion and post it for review. The idea would be to provide a simple one stop wiki page for people who want to contribute. cheers, --titus ___ 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
Re: [Python-Dev] Encouraging developers
On 3/7/07, Titus Brown [EMAIL PROTECTED] wrote: On Wed, Mar 07, 2007 at 11:10:22AM +0100, Martin v. L?wis wrote: - Giovanni Bajo schrieb: - On 06/03/2007 10.52, Martin v. L?wis wrote: - - I can't see that the barrier at contributing is high. - - I think this says it all. It now appears obvious to me that people - inside the mafia don't even realize there is one. Thus, it looks like - we are all wasting time in this thread, since they think there is - nothing to be changed. delurk Hi, I just wanted to interject -- when I used the word mafia, I meant it in this sense: Informal. A tightly knit group of trusted associates, as of a political leader: [He] is one of the personal mafia that [the chancellor] brought with him to Bonn. (Martin, I certainly didn't intend to offend anyone by implying that they were part of a criminal organization. ;) I have a longer explanation of my view in the blog entry, and anyway I don't want to belabor my own experiences too much, but I would like to point out three things: * there's definitely a group of trusted associates -- committers, perhaps? -- and it's not at all clear to outsiders like me how new features, old patches, and old bugs are dealt with. * python-dev is an all-volunteer community. In true open-source fashion, that means that it's incumbent upon people who HAVE problems/issues with a process (like me, and Giovanni) to propose solutions that either someone wants to implement, or that we can implement. I certainly don't expect any of the committers to put tons of effort into a new initiative. * Much of the discussion on this issue of encouraging developers comes down to communicating better with non-python-dev people. Unless someone is already doing it, I will try to write a summary of the last few days of discussion and post it for review. The idea would be to provide a simple one stop wiki page for people who want to contribute. My hope (along with many other hopes =), is to get a good document that explains exactly what is expected for bugs and patches in general and then what is specifically expected for things like new modules for the stdlib or new syntax proposals. With it all written in one place we have something to point people towards (basically what http://www.python.org/dev/intro/ was meant to be, but replaces most of what is in http://www.python.org/dev/). And I hope that once the tracker is up and we have some experience we can make it help us by possibly annotating issues with that they hare or are lacking (e.g., needs tests, needs docs, etc.). That way people can read this doc, understand what is expected for code and such, and then search the tracker for stuff that needs those thing and help deal with it. Basically make it so that if someone goes, I want to help write a test, they can find out what needs a test. But I get the docs for the new tracker written first. Once that is done I plan to start working on this doc (or docs if it gets too long) as my next big Python project. -Brett ___ 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
Re: [Python-Dev] Encouraging developers
Titus Brown schrieb: Hi, I just wanted to interject -- when I used the word mafia, I meant it in this sense: Informal. A tightly knit group of trusted associates, as of a political leader: [He] is one of the personal mafia that [the chancellor] brought with him to Bonn. (Martin, I certainly didn't intend to offend anyone by implying that they were part of a criminal organization. ;) Apology accepted. As to your specific comments: there's definitely a group of trusted associates -- committers, perhaps? Yes, but not all of the committers are part of the mafia, i.e. some never review any patches. Also, the mafia isn't tightly nit. I.e. they don't have a hidden agenda they follow, to implement a political quest or some such. and it's not at all clear to outsiders like me how new features, old patches, and old bugs are dealt with. The simple answer is when we have time. There really is not more to it. Some patches get higher attention, e.g. because they fix serious bugs. Proposed new features of don't get any attention by the mafia, because Python will just work fine without the new feature. Much of the discussion on this issue of encouraging developers comes down to communicating better with non-python-dev people. This is a two-sided thing, of course. The non-python-dev people should also communicate with the python-dev ones, instead of forming false (and unconfirmed) assumptions on how things really work. It's easy to assume conspiracy everywhere, much harder to understand that the people you are interacting with are regular humans who contribute to open source for the same reasons as the next guy. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Facundo Batista schrieb: I finally understood the problem, and build python from the repository, and made the tests from *this* python (actually, this was an easy step because I'm on Ubuntu, but *I* would be dead if working in Windows, for example). Ok. *Me*, that I'm not ashame of asking what I don't know, if I didn't resolve it I'd finally asked in python-dev. But how many people would have throw the towel withoug getting so far? How many people want to submit a patch, or even a bug, or finds a patch to review, but don't know how to do something and thinks that python-dev is not the place to ask (too high minds and experienced people and everything)? If people want to contribute to open source, they just need to learn the rules. One of the primary rules is that most of it is a meritocracy: it's not high minds that give reputation, but past contributions. Sure, some people will be shied (sp?) away by merely thinking about python-dev. For them, the barrier is high for *any* contribution to open source software. What I propose is a dedicated place (mailing list, for example), that is something like a place where you can go and ask the silliest questions about helping in the developing process. In principle, python-dev should be such a place, but I can see how it isn't (due to nobody's fault). However, people should feel free to ask any question on [EMAIL PROTECTED], and actually do so. - How can I know if a patch is still open? Easy: if it's marked as Open. - I found a problem, and know how to fix it, but what else need to do? Go to www.python.org, then CORE DEVELOPMENT, then Patch submission. - Found a problem in the docs, for this I must submit a patch or tell something about it? How? Read CORE DEVELOPMENT, Intro to development. - I found an error in the docs, and fixed it, but I'm spanish speaker and my english sucks, can I submit a patch with bad wording or I must ask somebody to write it ok? What would your intuition tell you to do? Me, for example, has an actual question to this list: How can I know, if I change something in the doc's .tex files, that I'm not broking the TeX document structure?. You don't have to know. As a general contributor, just submit your patch, and perhaps the reviewer will catch the error. As a submitter, just submit the code, and George Yoshida will catch it. It's not strictly necessary that the documentation actually builds all the time. If you want to be sure it builds, run make html in Doc. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Georg Brandl schrieb: Of course, the channel would have to be made an official Python development tool and advertised on e.g. the website. Also, it couldn't hurt if some of the other devs would frequent it too, then :) I definitely won't: I don't use IRC (or any other chat infrastructure), as a matter of principle. The only way to talk to me in real time is in person, or on the phone. (I do make an exception for the PSF board). Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
On 3/7/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Me, for example, has an actual question to this list: How can I know, if I change something in the doc's .tex files, that I'm not broking the TeX document structure?. You don't have to know. As a general contributor, just submit your patch, and perhaps the reviewer will catch the error. As a submitter, just submit the code, and George Yoshida will catch it. It's not strictly necessary that the documentation actually builds all the time. If you want to be sure it builds, run make html in Doc. Even better, the same machine running refleaks every 12 hours also builds the docs. It will complain if the docs don't build, so be aggressive with the docs. Any failures are sent do python-checkins. You can also see the results from trunk here: http://docs.python.org/dev/ http://docs.python.org/dev/results/ Here are the 2.5 results (only builds doc, not refleak test): http://docs.python.org/dev/2.5/ http://docs.python.org/dev/2.5/results/ These pages are generated from Misc/build.sh. As I mentioned, build.sh runs every 12 hours. n ___ 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
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 5:42 am, Martin v. Löwis wrote: Phil Thompson schrieb: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. People don't *have* to review patches. They just can do that if they want expedite review of their code. 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I doubt this will help. Much of the code isn't owned by anybody specifically. Those parts that are owned typically find their patches reviewed and committed quickly (e.g. the tar file module, maintained by Lars Gustäbel). Doesn't your last sentence completely contradict your first sentence? 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. So what do you do with core developers that don't do their job? Fire them? Of course not, but this is a cultural issue not a technical one. The first step in changing a culture is to change the expectations. Phil ___ 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
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote: Phil Thompson schrieb: I'm not sure what your point is. My point is that, if you want to encourage people to become core developers, they have to have a method of graduating through the ranks - learning (and being taught) as they go. To place a very high obstacle in their way right at the start is completely counter-productive. And please be assured that no such obstacle is in the submitters way. Most patches are accepted without the submitter actually reviewing any other patches. I'm glad to hear it - but I'm talking about the perception, not the fact. When occasionally submitters ask if their patch is going to be included, they will usually get a response suggesting they review other patches. That will only strengthen the perception. This discussion started because the feeling was expressed that it was difficult to get patches accepted and that new core developers were not being found. I would love to contribute more to the development of Python - I owe it a lot - but from where I stand (which is most definitely not where you stand) I can't see how to do that in a productive and rewarding way. Phil ___ 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
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 6:00 am, Martin v. Löwis wrote: Phil Thompson schrieb: 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. I don't think that that is true. I think a lot of people care, but many can't do anything about because the barrier to entry is too great. He was talking about the committers specifically who don't care about Python as-a-whole, and I think this is true. But I also believe that many contributors don't care about Python as-a-whole, in the sense that they are uninterested in learning about implementation details of libraries they will never use. What they do care about is the problems they have, and they do contribute patches for them. 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. So there is something wrong there as well. 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. Of course it's not unreasonable. I would expect to be told that a patch must have tests and docs before it will be finally accepted. However, before I add those things to the patch I would like some timely feedback from those with more experience that my patch is going in the right direction. This cannot work. It is very difficult to review a patch to fix a presumed bug if there is no test case. You might not be able to reproduce the patch without a test case at all - how could you then know whether the patch actually fixes the bug? Please read what I said again. Yes, a patch must be reviewed before submission. Yes, a patch when submitted must include docs and test cases. I'm talking about the less formal process leading up to that point. The less formal process has a much lower barrier to entry, requires much less effort by the reviewer, is the period during which the majority of the teaching happens, and will result in a better quality final patch that will require less effort to be put in to the final, formal review. So I really think patches should be formally complete before being submitted. This is an area were anybody can review: you don't need to be an expert to see that no test cases are contributed to a certain patch. If you really want to learn and help, review a few patches, to see what kinds of problems you detect, and then post your findings to python-dev. People then will comment on whether they agree with your review, and what additional changes they like to see. Do you think this actually happens in practice? There is no point sticking to a process, however sensible, if it doesn't get used. Phil ___ 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
Re: [Python-Dev] Encouraging developers
On 3/6/07, Phil Thompson [EMAIL PROTECTED] wrote: On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote: Phil Thompson schrieb: I'm not sure what your point is. My point is that, if you want to encourage people to become core developers, they have to have a method of graduating through the ranks - learning (and being taught) as they go. To place a very high obstacle in their way right at the start is completely counter-productive. And please be assured that no such obstacle is in the submitters way. Most patches are accepted without the submitter actually reviewing any other patches. I'm glad to hear it - but I'm talking about the perception, not the fact. When occasionally submitters ask if their patch is going to be included, they will usually get a response suggesting they review other patches. That will only strengthen the perception. This discussion started because the feeling was expressed that it was difficult to get patches accepted and that new core developers were not being found. I would love to contribute more to the development of Python - I owe it a lot - but from where I stand (which is most definitely not where you stand) I can't see how to do that in a productive and rewarding way. I recognize there is a big problem here. Each of us as individuals don't scale. So in order to get stuff done we need to be more distributed. This means distributing the workload (partially so we don't burn out). In order to do that we need to distribute the knowledge. That probably involves some changes. I understand it's really hard to get involved. It can be frustrating at times. But I think the best way is to find a mentor. Find an existing core developer that you relate to and/or have similar interests with. I've been trying to do this more. So here's my offer. Anyone who is serious about becoming a Python core developer, but doesn't know how to get involved can mail me. Privately, publicly, it doesn't matter to me. I will try to mentor you. Be prepared! I will demand submissions are high quality which at a minimum means: - it adds a new test, enhances an existing test or fixes a broken test - it has *all* the required documentation, including versionadded/versionchanged - most people think the feature is desirable - the code is maintainable and formatted according to the prevailing style - we follow the process (which can include improving the process if others agree) ie, there's no free lunch, unless you work at Google of course :-) It also means you are willing to hold other people up to equally high standards. Your contributions don't have to be code though. They can be doc, they can be PEPs, they can be the python.org website. It could even be helping out with Google's Summer of Code. The choice is yours. n ___ 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
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 6:15 am, Raymond Hettinger wrote: [Phil Thompson] I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Do you mean commit priviledges? ISTM, those tend to be handed out readily to people who assert that they have good use for them. Ask the Georg-bot how readily he was accepted and coached. IMO, his acceptance was a model that all open source projects should aspire to. If you meant something else like knowing how to make a meaningful patch, then you've got a point. It takes a while to learn your way around the source tree and to learn the inter-relationships between the moving parts. That is just the nature of the beast. I meant the second. While it may be the nature that doesn't mean that the situation can't be improved. [MvL] 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. [Phil] So there is something wrong there as well. I have not idea what you're getting at.Martin's comment seems accurate to me. Unless it is a simple typo/doc fix, it takes some time to assess whether the bug is real (some things are bugs only in the eye of the submitter) and whether the given fix is the right thing to do. Of course, automatic acceptance of patches would be a crummy idea. There have been no shortage of patches complete with docs and tests that were simply not the right thing to do. My point is simply that the effort required to review patches seems to be a problem. Perhaps the reasons for that need to be looked at and the process changed so that it is more effective. At the moment people just seem be saying that's the way it is because that's the way it's got to be. [Phil] The process needs to keep people involved in it - at the moment submitting a patch is fire-and-forget. Such is the nature of a system of volunteers. If we had full-time people, it could be a different story. IMO, given an 18 month release cycle, it is perfectly acceptable for a patch to sit for a while until someone with the relavant expertise can address it. Even with a tests and docs, patch acceptance is far from automatic. That being said, I think history has shown that important bugs get addressed and put into bug fix releases without much loss of time. When Py2.5.1 goes out, I expect that all known, important bugs will have been addressed and that's not bad. Then perhaps getting a full-time person should be taken seriously. Phil ___ 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
Re: [Python-Dev] Encouraging developers
Stephen J. Turnbull schrieb: An informal version of this process is how XEmacs identifies its Reviewers (the title we give to those privileged to authorize commits to all parts of XEmacs). People who care enough to make technical comments on *others'* patches are rare, and we grab the competent ones pretty quickly. My experience exactly. Besides Georg Brandl, I think this was also how Raymond Hettinger started his regular contributions to Python. The mess is not total, as Josiah Carlson points out. To the extent that it is a mess, it is the consequence of a process similar to the one you propose to institutionalize. It wasn't clear to me that this is the case, but I think you are exactly right. Those libraries that are now considered a mess had been ad-hoc contributions in many cases, with a single use case (namely the one of the original contributor). The contributor is not to blame, of course: he could only contribute what he has experience with. I wouldn't blame the committers who accepted the libraries, either - much of Python's value is in libraries included. So to fix the total mess, one has to replace the libraries with better ones, were available, learning from past experience to not accept libraries that had not been widely tested in the field. Second, where the stdlib module is closely bound to the core, the maintainer ends up being the group of core developers. It can't be any other way, it seems to me. It might be that individuals get designated maintainers: Guido maintains list and tuple, Tim maintaines dict, Raymond maintains set, I maintain configure.in. However, I doubt that would work in practice. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
On 3/6/07, Neil Schemenauer [EMAIL PROTECTED] wrote: Using git-svn to track a SVN repository seems to work well. I'm not interested in setting up GIT myself, mostly because it doesn't solve any issues that other dvcs' don't solve, the on-disk repository is mighty big and it doesn't work very well on non-Linux systems (at least, not last I looked.) If you want to set it up and maintain it, though, that's fine by me. I would like to point out that while it takes only a few minutes to setup a new repository and start the conversion for any of the SCM's (not just distributed ones), that doesn't mean it's a no-brainer to set them up 'officially', and maintain them :) There's a lot more work in there, so be prepared to spend some time to get it to work right and reliable for everyone. -- 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
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I doubt this will help. Much of the code isn't owned by anybody specifically. Those parts that are owned typically find their patches reviewed and committed quickly (e.g. the tar file module, maintained by Lars Gustäbel). Doesn't your last sentence completely contradict your first sentence? No (not sure how you are counting: there are three sentences): 1. Public identification will not help, because: 2. most code isn't in the responsibility of anybody (so publically identifying responsibilities would leave most code unassigned), and 3. for the code that has some responsible member, things are already fine (so public identification won't improve here) Maybe you meant to suggest assign responsibilities to core developers, then identify them publically; this is different from merely publically announcing already-assigned specific responsibilities. The latter won't work for the reasons discussed; the former won't work because these are volunteers, you can't assign anything to them. 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. So what do you do with core developers that don't do their job? Fire them? Of course not, but this is a cultural issue not a technical one. The first step in changing a culture is to change the expectations. I think the expectations of the users of Python have to adjust, then. This is free software, it has its own working principles that people need to get used to. In essence: if you want change, you need to execute it your own. Nobody will do it for you. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: And please be assured that no such obstacle is in the submitters way. Most patches are accepted without the submitter actually reviewing any other patches. I'm glad to hear it - but I'm talking about the perception, not the fact. When occasionally submitters ask if their patch is going to be included, they will usually get a response suggesting they review other patches. That will only strengthen the perception. That's because those who get their patches accepted quickly never complain. They are still the majority, though. In case of Titus Brown (who complained in his blog), I found that all of his 5 patches got integrated into Python, me committing four of them, and Georg committing one. Response time was between 3 days and 16 months. This discussion started because the feeling was expressed that it was difficult to get patches accepted and that new core developers were not being found. I would love to contribute more to the development of Python - I owe it a lot - but from where I stand (which is most definitely not where you stand) I can't see how to do that in a productive and rewarding way. Not sure how long you have been contributing to free software: you will find, over time, that it is rewarding to get changes accepted even if the process takes several months. Patience is an important quality here. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: Of course it's not unreasonable. I would expect to be told that a patch must have tests and docs before it will be finally accepted. However, before I add those things to the patch I would like some timely feedback from those with more experience that my patch is going in the right direction. This cannot work. It is very difficult to review a patch to fix a presumed bug if there is no test case. You might not be able to reproduce the patch without a test case at all - how could you then know whether the patch actually fixes the bug? Please read what I said again. I did - I can't see where I misunderstood. You said you want feedback on the patch even if it doesn't have test and doc changes (before I add those things), and I said the only feedback you'll likely get is add test cases and doc changes. Yes, a patch must be reviewed before submission. Yes, a patch when submitted must include docs and test cases. I'm talking about the less formal process leading up to that point. The less formal process has a much lower barrier to entry, requires much less effort by the reviewer, is the period during which the majority of the teaching happens, and will result in a better quality final patch that will require less effort to be put in to the final, formal review. Here I'm not sure what you are talking about. How would that process be executed? On python-dev? On the patches tracker? It often happens that people write a bug report, and I respond yes, this is a bug, would you like to work on a patch? They then either ask should I do it this or that way?, and then I give my opinion. So this already happens - again, it's just that the people don't talk much about it. I can't see that the barrier at contributing is high. The number of patch submissions and bug reports proves the contrary. Literally hundreds of people contribute. If you really want to learn and help, review a few patches, to see what kinds of problems you detect, and then post your findings to python-dev. People then will comment on whether they agree with your review, and what additional changes they like to see. Do you think this actually happens in practice? I wasn't talking in general, I was talking specifically about you (Phil Thompson) here. If you really want to contribute in *maintaining* Python, you are more than welcome. Several current committers found their way into python-dev in the way you described, and nearly nobody was ever turned away. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: My point is simply that the effort required to review patches seems to be a problem. Perhaps the reasons for that need to be looked at and the process changed so that it is more effective. At the moment people just seem be saying that's the way it is because that's the way it's got to be. We have already changed the process a lot. These days patches are regularly turned away for not having tests and doc changes in them. Yet, there are no reviewers willing to contribute even this very straight-forward, easy-to-execute check. If the patch meets the formal criteria, the hard part (on the reviewers side) starts: they must understand the code being patched, the nature of the problem, and the patch itself. I don't see how this could be simplified, without neglecting quality. Then perhaps getting a full-time person should be taken seriously. That's quite expensive, plus somebody would need to supervise that person. A part-time person would be less expensive, but still needs supervision. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson writes: MvL wrote: I doubt this will help. Much of the code isn't owned by anybody specifically. Those parts that are owned typically find their patches reviewed and committed quickly (e.g. the tar file module, maintained by Lars Gustäbel). Doesn't your last sentence completely contradict your first sentence? Not in view of the second one. Martin is saying that where the existing process looks like your suggestion, it already works great. It's not that this isn't well-known to the core developers! The problem is a lack of reviewers/module owners. The existing review-for-review *offer* (not requirement!) proposes to increase the supply of reviewers by offering them good and valuable consideration (ie, a fast track for their own patches) in return. You may not wish to take advantage of that offer, but it addresses the underlying problem. The other proposals on the table amount to (a) the existing reviewers should work harder and (b) if patches aren't reviewed, then they should be presumed good enough to apply. I think it should be obvious how far they will get when restated in those practical terms. ___ 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis writes: Stephen J. Turnbull schrieb: Second, where the stdlib module is closely bound to the core, the maintainer ends up being the group of core developers. It can't be any other way, it seems to me. It might be that individuals get designated maintainers: Guido maintains list and tuple, Tim maintaines dict, Raymond maintains set, I maintain configure.in. However, I doubt that would work in practice. I was referring more to modules like os than to language features. My experience with XEmacs is that 3rd parties are generally surprised at how wide the range of packages that are considered to require the blessing of a core developer before messing with them. ___ 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
Re: [Python-Dev] Encouraging developers
On 06/03/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Scott Dial schrieb: While I understand that this tit-for-tat mechanism is meant to ensure participation, I believe in reality it doesn't, as the 400-some outstanding patches you referenced elswhere indicate. I can personally attest to having a patch that is over a year old with no core developer having any interest at all with the subject matter. And to be frank, nor did I really, but I saw a problem and was capable of solving it. My lack of caring about the patch means I am not going to beat people over the head to pay attention. This system is broken for someone like me (coder) that just wants to help out (non-coders). If you don't care that much about the patch, it's not broken. As I said before, the number of unreviewed patches has been roughly stable for some time now. If the patch is not really important, it may take two years now to get it in, but eventually, it will (if you then still are interested to work on it to complete it). Here's a random offer - let me know the patch number for your patch, and I'll review it. Note that I do *not* consider myself a core developer, I don't even have the tools these days to build Python easily - I certainly haven't done so for a while. The likelihood is that I don't know much about the subject area of your patch, either. As a final disclaimer, note that I have no commit privilege, so my review won't result in your patch actually being applied :-) I'll post the results of my review here, as an example of what a reviewer needs to look at. If someone wants to distil that into a set of how to review a patch guidelines, then that's great. More reviewers would be a huge benefit. I agree that contributing feels hard, and often the hard bit is gaining the attention of the committers. The 5-for-1 offers help this, and shouldn't be dismissed - it's just that the *other* ways involve people skills (and so are far harder!!!) Maybe we should emphasize (again) that reviewing patches is also contributing, and would be greatly appreciated. Paul. ___ 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
Re: [Python-Dev] Encouraging developers
Paul Moore schrieb: Scott Dial schrieb: While I understand that this tit-for-tat mechanism is meant to ensure participation, I believe in reality it doesn't, as the 400-some outstanding patches you referenced elswhere indicate. I can personally attest to having a patch that is over a year old with no core developer having any interest at all with the subject matter. Here's a random offer - let me know the patch number for your patch, and I'll review it. Surprisingly (and I hope Scott can clarify that), I can't find anything. Assuming Scott's SF account is geekmug, I don't see any open patches (1574068 was closed within 20 days by amk, last October). Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Raymond Hettinger schrieb: [Phil Thompson] I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Do you mean commit priviledges? ISTM, those tend to be handed out readily to people who assert that they have good use for them. Ask the Georg-bot how readily he was accepted and coached. IMO, his acceptance was a model that all open source projects should aspire to. Indeed. For me, it wasn't hard to get tracker rights. I reviewed some patches, commented on bugs, posted suggestions to python-dev etc. When I asked about tracker rights on python-dev, they were given to me. Then, it wasn't hard to get commit rights. I contributed some stuff, and after a while I asked about commit rights on python-dev, and they were given to me on condition that I still let a core dev review inteded changes. As far as I recall, there has been nearly no one who asked for commit rights recently, so why complain that the entry barrier is too great? Surely you cannot expect python-dev to got out and say would you like to have commit privileges?... Georg ___ 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
Re: [Python-Dev] Encouraging developers
On 3/6/07, Georg Brandl [EMAIL PROTECTED] wrote: Raymond Hettinger schrieb: [Phil Thompson] I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Do you mean commit priviledges? ISTM, those tend to be handed out readily to people who assert that they have good use for them. Ask the Georg-bot how readily he was accepted and coached. IMO, his acceptance was a model that all open source projects should aspire to. Indeed. For me, it wasn't hard to get tracker rights. I reviewed some patches, commented on bugs, posted suggestions to python-dev etc. When I asked about tracker rights on python-dev, they were given to me. Then, it wasn't hard to get commit rights. I contributed some stuff, and after a while I asked about commit rights on python-dev, and they were given to me on condition that I still let a core dev review inteded changes. As far as I recall, there has been nearly no one who asked for commit rights recently, so why complain that the entry barrier is too great? Surely you cannot expect python-dev to got out and say would you like to have commit privileges?... You can ask whether we should have a plan for increasing the number of developers, actively seeking out new developers, and mentoring people who express interest. Would the code be better if we had more good developers working on it? Would we get more bugs fixed and patches closed? If so, it wouldn't hurt to have some deliberate strategy for bringing new developers in. I can easily imagine someone spending a lot of time mentoring and a little time coding, but having a bigger impact that someone who only wrote code. Jeremy ___ 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
Re: [Python-Dev] Encouraging developers
Georg Brandl wrote: As far as I recall, there has been nearly no one who asked for commit rights recently, so why complain that the entry barrier is too great? Surely you cannot expect python-dev to got out and say would you like to have commit privileges?... I think the number one suggestion I can make to anyone who is genuinely interested in contributing to the Python core is to lurk on python-dev for a while. It *does* require a reasonable time commitment (much more than the time required to fire a one-off patch at the SF tracker), but I've certainly found it to be a valuable learning experience (both in general and in relation to Python core development): - getting an idea of who's who (and what's what) in the Python world - getting an idea of what needs to be done in CPython development - seeing bugs and patches discussed (yes, it happens!) - learning various non-Python specific things ranging from good API design and doing object-oriented programming in C to the intricacies of binary floating point, Unicode and POSIX signal handling (etc, etc, ...) I believe my personal involvement in core development followed a similar trajectory to Georg's - lurked on python-dev for a while, began participating in discussions before too long (I'm not very good at lurking ;), helped out with the initial addition of the decimal module, got tracker privileges to help out with various bugs and patches, then eventually got commit privileges in order to update PEP 343. And I think this approach still works - it's just that it is mainly useful to people that are interested in Python core development in general, rather than those that are looking to get a specific bug fixed or patch accepted (although the latter can happen too - Lars was given commit privileges when it became clear that he was both willing and able to be the maintainer of the tarfile module). One thing that did happen though (which the messages from Jeremy Phil reminded me of) is that I got a lot of direction, advice and assistance from Raymond when I was doing that initial work on improving the speed of the decimal module - I had the time available to run the relevant benchmarks repeatedly and try different things out, while Raymond had the experience needed to suggest possible avenues for optimisation (and when to abandon an approach as making the code too complicated to be effectively maintained). I don't know whether or not there is anything specific we can do to encourage that kind of coaching/mentoring activity, but I know it was a significant factor in my become more comfortable with making contributions. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Encouraging developers
On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote: My point is simply that the effort required to review patches seems to be a problem. Perhaps the reasons for that need to be looked at and the process changed so that it is more effective. At the moment people just seem be saying that's the way it is because that's the way it's got to be. Unfortunately I think the effort required is intrinsic to reviewing patches. Trivial or obviously correct patches get applied quickly, so the remaining bugs and patches are the ones that are hard to fix. For example, our oldest bug is http://www.python.org/sf/214033, opened 2000-09-11, and is that (x?)? is reported as an error by the SRE regex parser; the PCRE engine and Perl both accept it. Fixing it requires changing sre_parse, figuring out what to do (should it be equivalent to '(x?)' or to '(x)?', and then being very sure that no other patterns are broken by the change. I suspect that fixing this bug properly by researching the right answer, implementing it, and adding tests would take me a half-day's worth of work. If modifying sre_parse is very difficult, it could take longer. --amk ___ 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
Re: [Python-Dev] Encouraging developers
Jeremy Hylton schrieb: You can ask whether we should have a plan for increasing the number of developers, actively seeking out new developers, and mentoring people who express interest. Would the code be better if we had more good developers working on it? Would we get more bugs fixed and patches closed? Certainly, yes. If so, it wouldn't hurt to have some deliberate strategy for bringing new developers in. Well, it might hurt. I do have a strategy: I force people eager to get their patches included into reviewing, with the 5:1 deal. I do consider it a useful strategy, and feel sorry that nobody else was willing to adopt it. However, it seems that this also has hurt, because now some people believe this is the only way to get patches reviewed (but perhaps that's not too bad, because before they believed there is no way at all to get patches reviewed...). Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Nick Coghlan schrieb: One thing that did happen though (which the messages from Jeremy Phil reminded me of) is that I got a lot of direction, advice and assistance from Raymond when I was doing that initial work on improving the speed of the decimal module - I had the time available to run the relevant benchmarks repeatedly and try different things out, while Raymond had the experience needed to suggest possible avenues for optimisation (and when to abandon an approach as making the code too complicated to be effectively maintained). I don't know whether or not there is anything specific we can do to encourage that kind of coaching/mentoring activity, but I know it was a significant factor in my become more comfortable with making contributions. While there was no explicit management of a mentoring process, I think it so happened that committers always found a mentor. It so happened that some developer activated privileges for them (either himself, or requesting that this be done), and then certainly feels responsible for his 'student'. This automatically establishes a mentoring relationship. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
A.M. Kuchling schrieb: For example, our oldest bug is http://www.python.org/sf/214033, opened 2000-09-11, and is that (x?)? is reported as an error by the SRE regex parser; the PCRE engine and Perl both accept it. Fixing it requires changing sre_parse, figuring out what to do (should it be equivalent to '(x?)' or to '(x)?', and then being very sure that no other patterns are broken by the change. I suspect that fixing this bug properly by researching the right answer, implementing it, and adding tests would take me a half-day's worth of work. If modifying sre_parse is very difficult, it could take longer. I just applied a patch by Aaron Watters for HTMLParser, which was three years old. The patch wasn't contributed in unified diff, it hadn't test cases and documentation changes, and it changed the way HTMLParser does unescaping of references in HTML attributes. It was a fairly small change, yet it contained a bug, and a likely-to-occur boundary behavior (entity references for undefined entities). In testing, I found that HTMLParser (incorrectly) supports apos; and decided to continue to support it for compatibility. All in all, it took me about one hour to review and apply this patch (again, even though it changed only 20 lines or so). I felt it wouldn't have been fair to Aaron to go back and ask for unified diffs etc now that the patch had been sitting there for several years. Yet, in all these years, nobody else commented that the patch was incomplete, let alone commenting on whether the feature was desirable. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis schrieb: Nick Coghlan schrieb: One thing that did happen though (which the messages from Jeremy Phil reminded me of) is that I got a lot of direction, advice and assistance from Raymond when I was doing that initial work on improving the speed of the decimal module - I had the time available to run the relevant benchmarks repeatedly and try different things out, while Raymond had the experience needed to suggest possible avenues for optimisation (and when to abandon an approach as making the code too complicated to be effectively maintained). I don't know whether or not there is anything specific we can do to encourage that kind of coaching/mentoring activity, but I know it was a significant factor in my become more comfortable with making contributions. While there was no explicit management of a mentoring process, I think it so happened that committers always found a mentor. It so happened that some developer activated privileges for them (either himself, or requesting that this be done), and then certainly feels responsible for his 'student'. This automatically establishes a mentoring relationship. Perhaps we should really try to make *that* notion widely known out there, opposed to others like the alleged 5:1 requirement or that it is hard to get patches into the Python core :) A sort of announcement and some text on the website would surely help... Georg ___ 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
Re: [Python-Dev] Encouraging developers
A.M. Kuchling schrieb: On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote: My point is simply that the effort required to review patches seems to be a problem. Perhaps the reasons for that need to be looked at and the process changed so that it is more effective. At the moment people just seem be saying that's the way it is because that's the way it's got to be. Unfortunately I think the effort required is intrinsic to reviewing patches. Trivial or obviously correct patches get applied quickly, so the remaining bugs and patches are the ones that are hard to fix. Exactly. I often find myself looking at a patch or bug and turn away thinking I would need hours to review and check that in, while the developer who originally wrote the code might perhaps do it in much less time. It's not easy to apply patches to code that was written by others and that should stay as compatible as possible for all cases not covered by the patch. Georg ___ 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
Re: [Python-Dev] Encouraging developers
George Brandl writes: As far as I recall, there has been nearly no one who asked for commit rights recently, so why complain that the entry barrier is too great? Surely you cannot expect python-dev to got out and say would you like to have commit privileges?... Why not? It depends on how far out out is, but I was surprised how much effect we (at XEmacs) got by simply asking people who contributed a couple of patches if they would like to take on tracking + patch flow management for their own patches in return for direct access to the repository. Giving out authority to approve commits is another matter, but as long as the new people are willing to participate in the mechanics it's generally a management win to have more committers. The answer is more often than not no, but *thanks for asking*. Merely asking creates an atmosphere of openness and trust. That's a lot, when simply asking that developers of patches consider third parties' use cases is attacked as a high barrier to participation. And of course it's the most common path to greater authority. ___ 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
Re: [Python-Dev] Encouraging developers
On Tue, 6 Mar 2007, [ISO-8859-1] Martin v. L?wis wrote: Yet, in all these years, nobody else commented that the patch was incomplete, let alone commenting on whether the feature was desirable. Which actually brings up another point: in many cases even a simple comment by a core developer: yes this feature is desirable might be of considerable value as it's likely to increase chances that some other developer will decide to spend time on the patch Similarly, some bug reports are for border cases. A confirmation by a core developer: yes, that needs fixing might encourage someone else to submit a patch... I'd also suggest that request for test cases/docs comes after (or together with) suggestion that a feature is desirable in the first place. Ilya Regards, Martin ___ 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/ilya%40bluefir.net ___ 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
Re: [Python-Dev] Encouraging developers
Ilya Sandler schrieb: I'd also suggest that request for test cases/docs comes after (or together with) suggestion that a feature is desirable in the first place. It depends. I was going through some old patches today, and came across one that added a class to heapq. I couldn't tell (even after reading the code) what precisely all implications are, so I was unable to proceed review beyond please provide documentation saying what this is for. I would then be able to tell: a) whether it really does what it promises to do, and b) whether this is desirable to have I remember many occasions where a patch was rejected and never reconsidered (even after discussion on python-dev) because the submitter failed to clearly specify what the intention of the change was, as it turned out that the code didn't implement the intention, and people reviewing rejected it because they thought it was meant to do something else (namely, to do what it actually did). Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Nick I don't know whether or not there is anything specific we can do Nick to encourage that kind of coaching/mentoring activity, but I know Nick it was a significant factor in my become more comfortable with Nick making contributions. Martin While there was no explicit management of a mentoring process, I Martin think it so happened that committers always found a mentor. Could the Summer of Code be used as a vehicle to match up current developers with potentially new ones? The svn sandbox (or a branch) could serve as a place for developers to get their feet wet. Perhaps Raymond can comment on whether he thinks that makes sense based upon his experience mentoring the Decimal-in-C module. 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 1. Public identification will not help, because: 2. most code isn't in the responsibility of anybody (so publically identifying responsibilities would leave most code unassigned), and 3. for the code that has some responsible member, things are already fine (so public identification won't improve here) If I were looking for an 'ophan' (python-coded) module to adopt, then such a list would help me choose. It would also be helpful if the new tracker system could produce a list of module-specific open items sorted by module, since that would indicate modules needing attention, and I could look for a batch that were unassigned. Terry Jan Reedy ___ 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
Re: [Python-Dev] Encouraging developers
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
Re: [Python-Dev] Encouraging developers
On Tue, Mar 06, 2007 at 01:03:39PM -0600, [EMAIL PROTECTED] wrote: Could the Summer of Code be used as a vehicle to match up current developers with potentially new ones? The svn sandbox (or a branch) could serve as a place for developers to get their feet wet. Perhaps Raymond can comment on whether he thinks that makes sense based upon his experience mentoring the Decimal-in-C module. Gregory Johnson, who did the rewrite of mailbox.py in the 2005 SoC, did a very good job; the module went into 2.5 and, judging by the few bug reports that have come in, gained some users pretty quickly. He also vanished after SoC was over, which is unfortunate, but not due to anything in my mentoring (I hope!). --amk ___ 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
Re: [Python-Dev] Encouraging developers
On Tue, Mar 06, 2007 at 01:51:41PM -0600, [EMAIL PROTECTED] wrote: 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. snip This is *definitely* the core problem with this system, and has plagued every project to use a variant of it (including many small projects with only one developer who takes months to respond to email). I think one *advantage* of this system would be that, with patch submitters having a specific person to whom their patches should be addressed, non-responsiveness on that person's part would be detected and brought to the community's attention more quickly. It would help a great deal to have a very formalized system in place for promoting/demoting maintainers -- email templates with filterable subject lines and specific addresses to send them to, specific expected response times, etc. As someone else said in another thread, we all think that everyone thinks like us (I think that's tautological?). My thinking is that a lot of people like me would love to have a small corner of Python for which they are responsible. Dustin ___ 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
Re: [Python-Dev] Encouraging developers
Neal Norwitz wrote: I recognize there is a big problem here. Each of us as individuals don't scale. So in order to get stuff done we need to be more distributed. This means distributing the workload (partially so we don't burn out). In order to do that we need to distribute the knowledge. That probably involves some changes. Neil with deep insight states... In order to do that we need to distribute the knowledge. + 1000 I'm looking forward to a new tracker and hope it manages single projects... (patches and bugs) better. It would be great if we could search for items based on possibly the following conditions. patch_complete patch_reviewed patch_approved test_complete test_reviewed test_approved doc_complete doc_reviewed doc_approved For new features: pep_completed pep_reviewed pep_approved Finally: (after all the above applicable conditions are true) accept_reject (python-dev (or BDFL) approval) [*] *Note: Rejections could be done sooner if it obviously a bad idea. In the case of bugs, the tests would probably come first in order to verify and reproduce the specific bug. What something like this would do is effectively distribute knowledge as you suggest. For example someone good at writing docs could do a search for all patches that do not have doc's or need docs reviewed and contribute in that way. The same for someone interested in writing and reviewing tests. It would also be easy for python core developers to get a list of items that are completed *and* are reviewed and then go through those items that are up for final approval on py-dev on a regular schedule. If it's determined there still needs to be work on any one item, they can clear the specific flags, (needs better tests, clear all test flags, with a suggestion of action), Then when it is fixed and re-reviewed it will come up for final approval again when the next final patch review period comes around. (or sooner if a core developer wants to push it though.) I understand it's really hard to get involved. It can be frustrating at times. But I think the best way is to find a mentor. Find an existing core developer that you relate to and/or have similar interests with. I've been trying to do this more. So here's my offer. Anyone who is serious about becoming a Python core developer, but doesn't know how to get involved can mail me. Privately, publicly, it doesn't matter to me. I will try to mentor you. Cool! Thanks. Be prepared! I will demand submissions are high quality which at a minimum means: - it adds a new test, enhances an existing test or fixes a broken test - it has *all* the required documentation, including versionadded/versionchanged - most people think the feature is desirable - the code is maintainable and formatted according to the prevailing style - we follow the process (which can include improving the process if others agree) ie, there's no free lunch, unless you work at Google of course :-) It also means you are willing to hold other people up to equally high standards. I wouldn't expect less. Your contributions don't have to be code though. They can be doc, they can be PEPs, they can be the python.org website. It could even be helping out with Google's Summer of Code. The choice is yours. I wonder if a tracker could also have patch requests. Similar to bugs, except it's more of a todo list. Oh, never mind there is a feature request group already. Could that possibly be extended to other areas? _Ron ___ 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
Re: [Python-Dev] Encouraging developers
Terry Reedy schrieb: It would also be helpful if the new tracker system could produce a list of module-specific open items sorted by module, since that would indicate modules needing attention, and I could look for a batch that were unassigned. The new tracker will initially have the same category as the current one, but it will have the ability to group by them (and perhaps even count them). Of course, many bugs don't have a category set, so some volunteer would first need to go through all open bugs and categorize them. If, for Modules, you want a more fine-grained classification, it would be possible to add new categories, or add another field affected modules (multi-list, I assume). If there is a volunteer that would like to go through all bug reports and classify them according this finer category, I can work with the roundup maintainers to add that (although it will likely only happen after the switch to roundup - it is easy to extend the schema with additional fields if it is known exactly what they are). There is also a generic keywords field in the roundup tracker - perhaps the affected modules could become keywords. HTH, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Terry Reedy schrieb: | It would also be helpful if the new tracker system could produce a list of | module-specific open items sorted by module, since that would indicate | modules needing attention, and I could look for a batch that were | unassigned. | | The new tracker will initially have the same category as the current | one, but it will have the ability to group by them (and perhaps even | count them). | | Of course, many bugs don't have a category set, so some volunteer would | first need to go through all open bugs and categorize them. I'll take a look at the categories on SF and see if any are unclear to me. | If, for Modules, you want a more fine-grained classification, it | would be possible to add new categories, or add another field | affected modules (multi-list, I assume). I guess making each module a category would be too fine... | | If there is a volunteer that would like to go through all bug | reports and classify them according this finer category, I can | work with the roundup maintainers to add that (although it | will likely only happen after the switch to roundup - it is | easy to extend the schema with additional fields if it is | known exactly what they are). | | There is also a generic keywords field in the roundup | tracker - perhaps the affected modules could become keywords. I am presuming that it will be easier to write scripts to search and manipulate on the new tracker (whether to run on the tracker site or elsewhere). If so, then the information just needs to be recorded somewhere. An existing keywords field sounds good enough. Terry Jan Reedy ___ 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
Re: [Python-Dev] Encouraging developers
On Tuesday 06 March 2007 20:24, Martin v. Löwis wrote: It might be that individuals get designated maintainers: Guido maintains list and tuple, Tim maintaines dict, Raymond maintains set, I maintain configure.in. However, I doubt that would work in practice. That approach would simply give us many many single points of failure. For instance, you're maintaining a particular module but at the time an important bug/patch comes up, you're off on holidays, or busy, or the like. Sure, you could say this person is primary, and this person is backup but hell, there's a lot of different components that make up Python. That would be a maintenance and management nightmare. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] Encouraging developers
Martin If, for Modules, you want a more fine-grained classification, Martin it would be possible to add new categories, or add another field Martin affected modules (multi-list, I assume). Why not add some tag capability to the new tracker (maybe the generic keywords field you mentioned would suffice)? People could attach whatever tags seem appropriate. Limiting the tags to a (nearly) fixed set of categories or the names of modules seems limiting. Given a set of tags you could also do the tag cloud thing and be more buzzword compliant at the same time. ;-) 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
Re: [Python-Dev] Encouraging developers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 6, 2007, at 7:51 PM, [EMAIL PROTECTED] wrote: Why not add some tag capability to the new tracker (maybe the generic keywords field you mentioned would suffice)? People could attach whatever tags seem appropriate. Limiting the tags to a (nearly) fixed set of categories or the names of modules seems limiting. Given a set of tags you could also do the tag cloud thing and be more buzzword compliant at the same time. ;-) Jira had a way of automatically assigning certain categories to certain people. I think the term was project leader or some such. Of course, this didn't mean that someone else couldn't fix the bug or that the bug couldn't be reassigned to someone else, but at least it initially gives all issues to the person nominally responsible for it. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRe4Qh3EjvBPtnXfVAQIzegP/dzWv3DGAKy5p5nRR/aWU90DVQJnw/WfK 0PPHlNCDhgixnQvjLP/0B8feeeUXHW3dwvodFkYrtxTHze6airkJLl9bypxMGgRo Q7ckj+51cXxySHLj9+5FEkdFS9gxrpWf6+toZoGSVZ08Wa2Pz6v2Pa3Oiu5kgvZ4 LAKfdvbFDh8= =U1zJ -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Encouraging developers
On 3/6/07, Ron Adam [EMAIL PROTECTED] wrote: Neal Norwitz wrote: I'm looking forward to a new tracker and hope it manages single projects... (patches and bugs) better. It would be great if we could search for items based on possibly the following conditions. The best place to discuss these things are on tracker-discuss. I think everything is pretty much done, we are waiting for someone to help write doc (Brett knows more about this). We are also waiting until after 2.5.1 is out before we switch over so there aren't unforeseen issues with the release. Hopefully 2.5.1 will be out in a month. *Note: Rejections could be done sooner if it obviously a bad idea. Agreed. Note: I review nearly all traffic on patches through the mailing list. If I see someone say this patch should be rejected and I agree, I will do it immediately. I rarely do that because I don't see those comments. Mostly I just close duplicates that happen from time to time. In the case of bugs, the tests would probably come first in order to verify and reproduce the specific bug. Yup. Also write a test case if one doesn't exist. That will greatly speed debugging. Adding helpful information about what platform the problem occurs on can speed things up too. Writing a NEWS entry would also speed things up. This may sound kinda stupid, but if enough people help out, it might reduce the time it takes to fix a bug from 30 minutes to 15 minutes. If I only have 15 minutes to work on a problem, it's the difference between it getting fixed or remaining unresolved. What something like this would do is effectively distribute knowledge as you suggest. For example someone good at writing docs could do a search for all patches that do not have doc's or need docs reviewed and contribute in that way. The same for someone interested in writing and reviewing tests. Yes, every little bit helps! I wonder if a tracker could also have patch requests. Similar to bugs, except it's more of a todo list. Oh, never mind there is a feature request group already. Could that possibly be extended to other areas? I don't know what you mean, can you clarify? n ___ 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
Re: [Python-Dev] Encouraging developers
On 3/6/07, Terry Reedy [EMAIL PROTECTED] wrote: Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 1. Public identification will not help, because: 2. most code isn't in the responsibility of anybody (so publically identifying responsibilities would leave most code unassigned), and 3. for the code that has some responsible member, things are already fine (so public identification won't improve here) If I were looking for an 'ophan' (python-coded) module to adopt, then such a list would help me choose. os.listdir(os.path.dirname(os.__file__)) Does that help? :-) It's not really that far off, though. :-( Larger modules that have been contributed recently like subprocess and tarfile are well maintained. Most other modules are less so. Most of the modules don't have problems. However, many of the web-centric modules have outstanding issues, as does sre. I think some of the shell utility modules (shutil, path handling) have issues wrt portability. There are also many problems that only occur on one platform (most often Windows, AIX, or HP-UX). I won't touch these sorts of problems unless I can properly verify the problem and the fix. Generally problems in these areas don't have tests which make fixing them without access to the platform too costly IMO. asyncore has a lot of outstanding issues IIRC. Also many issues are documentation. I think it would be best for people to pick a module they are interested in and knowledgeable about. We could create a wiki that would be for informational use. If it works well, maybe we could formalize it. Start something, announce it to python-list or python-dev, and try it. If it works, we'll adopt it. It would also be helpful if the new tracker system could produce a list of module-specific open items sorted by module, since that would indicate modules needing attention, and I could look for a batch that were unassigned. Agreed. That's why I wanted keywords to be supported (which I believe they are). If we can slice and dice the issues up into categories, it will be easy to figure out where we need to spend more time. It also can be a great incentive to drop 5 issues to 0. Going from 977 to 972, just isn't as satisfying. n ___ 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
Re: [Python-Dev] Encouraging developers
Neal Norwitz wrote: On 3/6/07, Ron Adam [EMAIL PROTECTED] wrote: Neal Norwitz wrote: I'm looking forward to a new tracker and hope it manages single projects... (patches and bugs) better. It would be great if we could search for items based on possibly the following conditions. The best place to discuss these things are on tracker-discuss. I think everything is pretty much done, we are waiting for someone to help write doc (Brett knows more about this). We are also waiting until after 2.5.1 is out before we switch over so there aren't unforeseen issues with the release. Hopefully 2.5.1 will be out in a month. Cool! :-) *Note: Rejections could be done sooner if it obviously a bad idea. Agreed. Note: I review nearly all traffic on patches through the mailing list. If I see someone say this patch should be rejected and I agree, I will do it immediately. I rarely do that because I don't see those comments. Mostly I just close duplicates that happen from time to time. In the case of bugs, the tests would probably come first in order to verify and reproduce the specific bug. Yup. Also write a test case if one doesn't exist. That will greatly speed debugging. Adding helpful information about what platform the problem occurs on can speed things up too. Writing a NEWS entry would also speed things up. This may sound kinda stupid, but if enough people help out, it might reduce the time it takes to fix a bug from 30 minutes to 15 minutes. If I only have 15 minutes to work on a problem, it's the difference between it getting fixed or remaining unresolved. I never consider clarifying statements even a little bit stupid. Only a bit boring if I hear them more than a few times in a short time period. But that's definitely not a problem compared with not having them stated at all. For us who aren't (as) familiar with all the issues surround a bug or the specific code in question it can take considerably longer. What something like this would do is effectively distribute knowledge as you suggest. For example someone good at writing docs could do a search for all patches that do not have doc's or need docs reviewed and contribute in that way. The same for someone interested in writing and reviewing tests. Yes, every little bit helps! But the tracker needs to be able to actually track the status of individual items for this to work. Currently there's this huge list and you have to either wade though it to find out the status of each item, or depend on someone bring it to your attention. (This has been discussed before.) I wonder if a tracker could also have patch requests. Similar to bugs, except it's more of a todo list. Oh, never mind there is a feature request group already. Could that possibly be extended to other areas? I don't know what you mean, can you clarify? I suppose I'm thinking of things that are even more general than a feature request. Like possibly a research request. Or a request for something to be done first so that something else can then be done. Ron ___ 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
Re: [Python-Dev] Encouraging developers
On Mon, Mar 05, 2007 at 12:58:13PM -0600, [EMAIL PROTECTED] wrote: I'm not much of a version control wonk. How would these help? Can't the folks who need such stuff do some sort of anonymous svn checkout? The external developers can commit changes, revert them, etc. to their local repository, and still keep pulling changes from the python.org master as we commit them. With an anonymous SVN checkout, you can never commit changes back, so you can't commit your work in stages or roll back changes as those of us w/ commit privileges can. (svk adds distributed features on top of SVN; that would be another option.) --amk ___ 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
Re: [Python-Dev] Encouraging developers
A few meta-points: On 07:30 pm, [EMAIL PROTECTED] wrote: 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I'd like to stress that this is an important point; although we all know that Guido's the eventual decision makers, there are people whose opinions need to be influenced around particular areas of the code and whose opinions carry particular weight. *I* have trouble figuring out who these people are, and I think I have more than a casual outsider's understanding of the Python development process. 3. Provide a forum (a python-patch mailing list) where patches can be proposed, reviewed and revised informally but quickly. This reminds me of a post I really wanted to make after PyCon but rapidly became too sick to. The patches list really ought to be _this_ list. The fact that it isn't is indicative of a failure of the community. A good deal of the discussion here in recent months has either been highly speculative, or only tangentially related to Python's development, which is ostensibly its topic. We shouldn't really be talking about PR or deployment or any issues which aren't bug reports or patches here. I've certainly contributed somewhat to this problem myself, and I've made a resolution to stick to development issues here. This post itself is obviously in a grey area near the edge of that, but I do feel that, given the rather diverse population of readers here, we should collectively make the purpose of this forum explicit so that the python developers can use it to develop Python. One worrying trend I noticed at PyCon is that it seems that quite a lot of communication between core developers these days happens over private email. Core developers use private email to deal with pressing issues because python-dev has become crowded. This makes it difficult to see high-priority issues, as well as fostering an environment where every minor detail might get responded to with a cascade of me too posts or bike-shed discussions. The core guys have a lot of stuff to get done, and if there isn't an environment where they can do that in public, they're going to get it done in private. Taken together, all this has the overall effect of making the development process a lot harder to follow, which worsens, for example, issue #2 which I responded to above. It also creates a number of false impressions about what sort of development is really going on, since many posters here are not, in fact, working on core Python at all, just speculating about it. A few others have already pointed out the python-ideas list: http://mail.python.org/mailman/listinfo/python-ideas where the more speculative ideas should be discussed before being brought here as a patch or PEP. Of course, for more general discussion there's always good old python-list. As far as bike-shed discussions, we can all do our part by just considering what threads we all really have something useful to contribute to. Let's all try to put the python dev back in python-dev! ___ 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
Re: [Python-Dev] Encouraging developers
On Monday 05 March 2007 8:09 pm, Oleg Broytmann wrote: On Mon, Mar 05, 2007 at 07:30:20PM +, Phil Thompson wrote: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. I am afraid this could lead to proliferation of low-quality patches. A patch must touch at least code, documentation and tests, be tested itself and must not break other tests. These requirements demand higher expertise. I'm not sure what your point is. My point is that, if you want to encourage people to become core developers, they have to have a method of graduating through the ranks - learning (and being taught) as they go. To place a very high obstacle in their way right at the start is completely counter-productive. Phil ___ 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
Re: [Python-Dev] Encouraging developers
A.M. Kuchling [EMAIL PROTECTED] wrote: 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? Using git-svn to track a SVN repository seems to work well. It would be trivial to setup a cron job on one of the python.org machines that would create a publicly accessible repository. To get changes back into SVN is pretty easy too. Someone with SVN access would pull the changes into their own git repository and then use git-svn to commit them. In my experience, committed changes look just like they would if they were done without git. There are other tools out there for Bzr and Mercurial but I have no experience with them. I've used Bzr but git seems a better fit for python-dev, even though it's harder to learn. If some decides to do this, I suggest reading http://git.or.cz/gitwiki/GitCommonMistakes . Neil ___ 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
Re: [Python-Dev] Encouraging developers
On Monday 05 March 2007 9:38 pm, Thomas Wouters wrote: 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. I don't think that that is true. I think a lot of people care, but many can't do anything about because the barrier to entry is too great. 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. So there is something wrong there as well. 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. Of course it's not unreasonable. I would expect to be told that a patch must have tests and docs before it will be finally accepted. However, before I add those things to the patch I would like some timely feedback from those with more experience that my patch is going in the right direction. I want somebody to give it a quick look, not a full blown review. The process needs to keep people involved in it - at the moment submitting a patch is fire-and-forget. Phil ___ 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
Re: [Python-Dev] Encouraging developers
Neil Schemenauer [EMAIL PROTECTED] wrote: Using git-svn to track a SVN repository seems to work well. It would be trivial to setup a cron job on one of the python.org machines that would create a publicly accessible repository. I guess Andrew was looking for specific instructions. Install git and git-svn. For Debian stable, you can get them from http://backports.org/debian/pool/main/g/git-core/. Initialize the repository: git-svn init http://svn.foo.org/project/trunk Fetch versions from SVN: git-svn fetch I think the fetch can be run periodically from a cron job. The repository can be cloned via HTTP but it's much faster to use the git server which runs on it's own TCP port. Neil ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | On Monday 05 March 2007 6:46 pm, A.M. Kuchling wrote: | 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? | | 1. Don't suggest to people that, in order to get their patch reviewed, they | should review other patches. The level of knowledge required to put together | a patch is much less than that required to know if a patch is the right one. | | 2. Publically identify the core developers and their areas of expertise and | responsibility (ie. which parts of the source tree they own). | | 3. Provide a forum (a python-patch mailing list) where patches can be | proposed, reviewed and revised informally but quickly. | | 4. Acceptance by core developers that only half the job is developing the | core - the other half is mentoring potential future core developers. Tracker item review is an obvious bottleneck in Python development. In particular, reviewing patches appears not to be nearly as self-motivating as writing them, and other activities. So I think the PSF should pay one or more people to do so. Possibly set up a patch review fund and solicit donations. And, donators should get priority attention to their submissions. For commercial developers, this would probably be cheaper, given the value of their time, than reviewing five other submissions. Terry Jan Reedy ___ 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
Re: [Python-Dev] Encouraging developers
On Mon, Mar 05, 2007, Terry Reedy wrote: Tracker item review is an obvious bottleneck in Python development. In particular, reviewing patches appears not to be nearly as self-motivating as writing them, and other activities. So I think the PSF should pay one or more people to do so. Possibly set up a patch review fund and solicit donations. And, donators should get priority attention to their submissions. For commercial developers, this would probably be cheaper, given the value of their time, than reviewing five other submissions. There also seems to be a sense that we're waiting to get off SourceForge and using our own tracker. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I disrespectfully agree. --SJM ___ 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
Re: [Python-Dev] Encouraging developers
On 05/03/2007 20.30, Phil Thompson wrote: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. +1000. 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. My suggestion is: - keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). - if there's no maintainer for a module, the *first* volunteer can become so. - *any* patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) *must* be applied *unless* the maintainer objects in X days (if a maintainer exists... otherwise it will just go in). 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. Acceptance that any patch is better than no patch. There are many valid Python programmers out there, and there are many many patches to stdlib which really don't even require a good programmer to be written. -- Giovanni Bajo ___ 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
Re: [Python-Dev] Encouraging developers
On 05/03/2007 19.46, A.M. Kuchling wrote: 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. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Do we have any evidence that new developers are getting frustrated because they can't handle their patches well enough with the current tools? -- Giovanni Bajo ___ 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
Re: [Python-Dev] Encouraging developers
On 3/5/07, Giovanni Bajo [EMAIL PROTECTED] wrote: On 05/03/2007 19.46, A.M. Kuchling wrote: 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. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Do we have any evidence that new developers are getting frustrated because they can't handle their patches well enough with the current tools? We asked people attending the Python-Dev panel at PyCon whether the use of a distributed VCS would encourage them to work on the core so that they could do their own commits in their own branch and some people did raise their hands. Plus it's just handy sometimes to be able to do commits when you lack network access. -Brett ___ 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
Re: [Python-Dev] Encouraging developers
On 3/5/07, Brett Cannon [EMAIL PROTECTED] wrote: On 3/5/07, Giovanni Bajo [EMAIL PROTECTED] wrote: On 05/03/2007 19.46, A.M. Kuchling wrote: 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. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Do we have any evidence that new developers are getting frustrated because they can't handle their patches well enough with the current tools? [snip] Plus it's just handy sometimes to be able to do commits when you lack network access. Seconded. I don't know how much it impacts new developers, but I know I get frustrated because of this. Collin Winter ___ 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
Re: [Python-Dev] Encouraging developers
On Mon, Mar 05, 2007 at 11:30:06PM +, Neil Schemenauer wrote: I guess Andrew was looking for specific instructions. ... I'm happy to let the ball sit in Thomas's court until the Bazaar developers come out with 0.15 and run their conversion on the SVN repository. There's no burning hurry about getting this set up, so a few weeks of waiting is fine. --amk ___ 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
Re: [Python-Dev] Encouraging developers
On Mon, Mar 05, 2007 at 08:50:46PM -, [EMAIL PROTECTED] wrote: is indicative of a failure of the community. A good deal of the discussion here in recent months has either been highly speculative, or only tangentially related to Python's development, which is ostensibly its topic. We shouldn't really be talking about PR or deployment or any issues which aren't bug reports or patches here. I don't recall any PR threads in python-dev, but do agree that language speculations usually lead to long threads that are very boring. It would be nice to focus more on concrete development questions, and usually we do manage to focus when there's an impending release. One problem may be that there *aren't* maintainers for various subsystems; various people have contributed bugfixes and patches for, say, urllib, but I have no idea what single person I would go to for a problem. Is it worth creating a wiki page listing people and the modules they're responsible for? Or does something like this already exist? --amk ___ 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
Re: [Python-Dev] Encouraging developers
Giovanni Bajo [EMAIL PROTECTED] wrote: On 05/03/2007 20.30, Phil Thompson wrote: 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. Sometimes code is correct. Sometimes code is complete. Just because a module hasn't been significantly altered or updated recently doesn't mean that it is outdated or broken. Asyncore, for example, is more or less feature complete for a minimal asynchronous socket framework. Could it gain more features (like good SSL support) or have better error handling? Of course. But it passes the test suite (via test_asynchat), so I would consider it *not* broken. My suggestion is: - keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). - if there's no maintainer for a module, the *first* volunteer can become so. - *any* patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) *must* be applied *unless* the maintainer objects in X days (if a maintainer exists... otherwise it will just go in). Just because a patch doesn't break a module, doesn't mean the patch should be applied. Take, for example, any one of the patches currently offered against asyncore. One of them more or less changes the internal structure of the module for no other reason than to (in my opinion) be gratuitous. Certainly it has some good ideas, but it would be better to adapt portions rather than take it completely - which is what you are suggesting, and which is what would have happened due to the absence of an asyncore maintainer (until I took it up). 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. Acceptance that any patch is better than no patch. There are many valid Python programmers out there, and there are many many patches to stdlib which really don't even require a good programmer to be written. Maybe, but there are also many patches I've seen that cause the resulting code to not run, revert changes made to fix bugs, etc. Vetting patches is a pain in the butt, and accepting all patches that aren't objected to is a braindead approach to patching the standard library. Indeed, every module and package should have a known and documented maintainer, but that's really the only part of your suggestions in the message I'm replying to that I would agree with. The rest gets a -1. - Josiah ___ 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
Re: [Python-Dev] Encouraging developers
On 3/5/07, A.M. Kuchling [EMAIL PROTECTED] wrote: [snip] One problem may be that there *aren't* maintainers for various subsystems; various people have contributed bugfixes and patches for, say, urllib, but I have no idea what single person I would go to for a problem. Is it worth creating a wiki page listing people and the modules they're responsible for? Or does something like this already exist? I'd rather have this kind of ownership information attached to the individual module documentation, so interested parties don't have to go hunting around in the wiki for it. It would also be helpful to have some loose guidelines/requirements for how to become a module maintainer (e.g., we're looking for the following traits...). Collin Winter ___ 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
Re: [Python-Dev] Encouraging developers
A.M. Kuchling schrieb: 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. I think this perception is partially wrong. The number of unreviewed patches has been sitting around 400 for quite some time now - so it has not been getting worse. This is mostly thanks to the (very) few reviewers that deal with patches in areas out of their primary interest. I'd like to mention Georg Brandl here. I also doubt that accepting patches more quickly would give many more patch reviewers. Most submitters are happy if their patch is accepted, and couldn't care less about other people's patches. This is fine, of course - it just means that becoming more responsive (by whatever means) would not necessarily sustain. Any ideas for fixing this problem? I had this long-term offer of a 5:1 deal. I wish more current committers would offer a similar deal, then we would be able to promise this policy prominently. This, of course, requires that committers are willing to deal with patches even if they are no experts in the subject (i.e. they will need to become experts in the process of reviewing). It might be possible to reverse this policy also: we could decide that committers maintain their write privilege only if they process patches (say, one patch per month). That would be quite intrusive, so I doubt that committers will agree to it. 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? If it is this distributed repository aspect that people are after, I suggest they use svk (http://svk.elixus.org/view/HomePage). People can use it now if they want to, no need to provide additional infrastructure. For other systems, there is a choice of either hosting them at svn.python.org as well (i.e. dinsdale), or having the community host them. For dinsdale hosting, it requires a volunteer to set it up and maintain it. Given the low number of volunteers available for such tasks, I doubt this can work. For community hosting, again there is little administration necessary: hosters can already mirror svn.python.org, and run whatever conversion scripts are necessary. In this case, the task would be merely to communicate that people can already do that if they want to. Regards Martin P.S. I'm really pissed as being described as member of a mafia. ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. People don't *have* to review patches. They just can do that if they want expedite review of their code. 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). I doubt this will help. Much of the code isn't owned by anybody specifically. Those parts that are owned typically find their patches reviewed and committed quickly (e.g. the tar file module, maintained by Lars Gustäbel). 4. Acceptance by core developers that only half the job is developing the core - the other half is mentoring potential future core developers. So what do you do with core developers that don't do their job? Fire them? Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
[EMAIL PROTECTED] schrieb: The patches list really ought to be _this_ list. The fact that it isn't is indicative of a failure of the community. I disagree that python-dev isn't the patches list. People often discuss patches here (although much discussion is also in the tracker). One worrying trend I noticed at PyCon is that it seems that quite a lot of communication between core developers these days happens over private email. Do you know this for a fact? I'm a core developer, and I don't use private email much to discuss patches or other changes. About the only private mail that I exchange is about the mechanics of the release process (e.g. agreeing on specific days for a release). Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: I'm not sure what your point is. My point is that, if you want to encourage people to become core developers, they have to have a method of graduating through the ranks - learning (and being taught) as they go. To place a very high obstacle in their way right at the start is completely counter-productive. And please be assured that no such obstacle is in the submitters way. Most patches are accepted without the submitter actually reviewing any other patches. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Phil Thompson schrieb: 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. I don't think that that is true. I think a lot of people care, but many can't do anything about because the barrier to entry is too great. He was talking about the committers specifically who don't care about Python as-a-whole, and I think this is true. But I also believe that many contributors don't care about Python as-a-whole, in the sense that they are uninterested in learning about implementation details of libraries they will never use. What they do care about is the problems they have, and they do contribute patches for them. 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. So there is something wrong there as well. 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. Of course it's not unreasonable. I would expect to be told that a patch must have tests and docs before it will be finally accepted. However, before I add those things to the patch I would like some timely feedback from those with more experience that my patch is going in the right direction. This cannot work. It is very difficult to review a patch to fix a presumed bug if there is no test case. You might not be able to reproduce the patch without a test case at all - how could you then know whether the patch actually fixes the bug? So I really think patches should be formally complete before being submitted. This is an area were anybody can review: you don't need to be an expert to see that no test cases are contributed to a certain patch. If you really want to learn and help, review a few patches, to see what kinds of problems you detect, and then post your findings to python-dev. People then will comment on whether they agree with your review, and what additional changes they like to see. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Neil Schemenauer schrieb: I guess Andrew was looking for specific instructions. Install git and git-svn. For Debian stable, you can get them from http://backports.org/debian/pool/main/g/git-core/. Initialize the repository: git-svn init http://svn.foo.org/project/trunk Fetch versions from SVN: git-svn fetch I think the fetch can be run periodically from a cron job. The repository can be cloned via HTTP but it's much faster to use the git server which runs on it's own TCP port. And that's it? Won't you need to publish the repository somehow? Apache configuration? init.d scripts? Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Collin Winter schrieb: It would also be helpful to have some loose guidelines/requirements for how to become a module maintainer (e.g., we're looking for the following traits...). That is easy to answer: Review the patches of the module, and post a message to python-dev about your findings (proposals of acceptance or rejection). Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
[Phil Thompson] I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Do you mean commit priviledges? ISTM, those tend to be handed out readily to people who assert that they have good use for them. Ask the Georg-bot how readily he was accepted and coached. IMO, his acceptance was a model that all open source projects should aspire to. If you meant something else like knowing how to make a meaningful patch, then you've got a point. It takes a while to learn your way around the source tree and to learn the inter-relationships between the moving parts. That is just the nature of the beast. [MvL] 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. [Phil] So there is something wrong there as well. I have not idea what you're getting at.Martin's comment seems accurate to me. Unless it is a simple typo/doc fix, it takes some time to assess whether the bug is real (some things are bugs only in the eye of the submitter) and whether the given fix is the right thing to do. Of course, automatic acceptance of patches would be a crummy idea. There have been no shortage of patches complete with docs and tests that were simply not the right thing to do. [Phil] The process needs to keep people involved in it - at the moment submitting a patch is fire-and-forget. Such is the nature of a system of volunteers. If we had full-time people, it could be a different story. IMO, given an 18 month release cycle, it is perfectly acceptable for a patch to sit for a while until someone with the relavant expertise can address it. Even with a tests and docs, patch acceptance is far from automatic. That being said, I think history has shown that important bugs get addressed and put into bug fix releases without much loss of time. When Py2.5.1 goes out, I expect that all known, important bugs will have been addressed and that's not bad. Raymond ___ 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
Re: [Python-Dev] Encouraging developers
Scott Dial schrieb: While I understand that this tit-for-tat mechanism is meant to ensure participation, I believe in reality it doesn't, as the 400-some outstanding patches you referenced elswhere indicate. I can personally attest to having a patch that is over a year old with no core developer having any interest at all with the subject matter. And to be frank, nor did I really, but I saw a problem and was capable of solving it. My lack of caring about the patch means I am not going to beat people over the head to pay attention. This system is broken for someone like me (coder) that just wants to help out (non-coders). If you don't care that much about the patch, it's not broken. As I said before, the number of unreviewed patches has been roughly stable for some time now. If the patch is not really important, it may take two years now to get it in, but eventually, it will (if you then still are interested to work on it to complete it). If nothing else, as an outsider there is no way to know why your patch gets ignored while others get swiftly dealt with. Any sort of information like this would at least provide more transparency in what may appear to be elitest processes. This is what we would need volunteer reviewers for. We can send machine confirmations, but I doubt it would help. If you need a human response, somebody must send you one, demonstrating that they actually did look at the patch. If none of the committers have the time to do so, somebody else must send the manual confirmation. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Raymond Hettinger schrieb: [Phil Thompson] I think a lot of people care, but many can't do anything about because the barrier to entry is too great. Do you mean commit priviledges? ISTM, those tend to be handed out readily to people who assert that they have good use for them. Ask the Georg-bot how readily he was accepted and coached. IMO, his acceptance was a model that all open source projects should aspire to. Indeed. IIRC, he first posted a message (under pseudonym at the time): I reviewed these patches because I didn't have anything better to do. Shortly afterwards, he was a committer. Regards, Martin ___ 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
Re: [Python-Dev] Encouraging developers
Giovanni Bajo writes: On 05/03/2007 20.30, Phil Thompson wrote: 1. Don't suggest to people that, in order to get their patch reviewed, they should review other patches. The level of knowledge required to put together a patch is much less than that required to know if a patch is the right one. +1000. Been there, done that. If the submitter doesn't have a pretty good idea that a patch is the right one, he's making substantial demands on core developer time. +1000 suggests you think that core developers are using their time with ruinously low efficiency. I think the review some patches test is exactly the right one. The requirement is not that you channel the BFDL, it's that you read the patch and bring your own knowledge of the problem to bear. This has three benefits: (1) the reviewed patches get some comments; (2) the reviewed patches come to the attention of a committer; (3) the reviewer comes to the attention of a core developer, and can be considered for commit privileges, etc. An informal version of this process is how XEmacs identifies its Reviewers (the title we give to those privileged to authorize commits to all parts of XEmacs). People who care enough to make technical comments on *others'* patches are rare, and we grab the competent ones pretty quickly. 2. Publically identify the core developers and their areas of expertise and responsibility (ie. which parts of the source tree they own). The XEmacs experience has been that the core developers are ministers without portfolio. You can't wait around for the owner, who may be on Mars, and you rarely need to. I think this should be pushed to its extreme consequences for the standard library. Patching the standard library requires *much less* knowledge than patching the standard core. Basically, almost any Python developer in the wild can quickly learn a module and start patching it in a few days/weeks -- still, the stdlib is a total mess of outdated and broken modules. The mess is not total, as Josiah Carlson points out. To the extent that it is a mess, it is the consequence of a process similar to the one you propose to institutionalize. My suggestion is: - keep a public list of official maintainers for each and every package/module in the standard library (if any, otherwise explicitly specify that it's unmaintained). This is what XEmacs does; it works, but it's not as effective as you might hope. What happens for us is that many modules are maintained by an interest group disjoint from the core. By giving a representative of the interest group commit privileges, things get addressed pretty quickly and competently. However, this is a convenience for users of the module more than a way of kickstarting a development process (note that the interest group already exists). This requires a separate distribution of the standard library. Two points: recall the ElementTree thread. There were other plausible candidates. The XEmacs policy in such case is that they are all considered equally, and all are allowed to be distributed with the package distribution. In Python, this would conflict with TOOWTDI. Second, where the stdlib module is closely bound to the core, the maintainer ends up being the group of core developers. It can't be any other way, it seems to me. - if there's no maintainer for a module, the *first* volunteer can become so. I doubt this will work. It is usually the case that the first volunteer is acceptable, but it shouldn't be policy. - *any* patch to stdlib which follows the proper guidelines (have a test, don't break compatibility, etc.) *must* be applied *unless* the maintainer objects in X days (if a maintainer exists... otherwise it will just go in). This is an obviously bad idea. The stdlib needs to be deliberately pruned, not arbitrarily patched. ___ 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
Re: [Python-Dev] Encouraging developers
Giovanni Bajo writes: On 05/03/2007 19.46, A.M. Kuchling wrote: 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. I really believe this is just a red herring, pushed by some SCM wonk. The problem with patch submission has absolutely *nothing* to do with tools. Of course it does. How important is a matter for individual judgment, of course. The *frustration level* with the acceptance process is certainly related to the annoyance of locally maintaining a patch in the face of a flow of upstream changes. The distributed SCMs make this *much* easier, and therefore can reduce the frustration level, at *zero* expense to the core developers (anybody with read access can maintain such a read-only repo). This is a good thing. It *is* important that the core sanction and support official mirror repos. This may or may not help the acceptance process to improve; I believe you are correct, that it will have little direct impact on the acceptance process. Nevertheless, life for third-party developers will become somewhat more pleasant, especially as they have a much easier way to exchange and refine patches. This last can feed back into the review for review bargain. ___ 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
Re: [Python-Dev] Encouraging developers
On 5 Mar, 2007, at 19:58, [EMAIL PROTECTED] wrote: amk Any ideas for fixing this problem? Not a one. amk Tangentially related: amk At PyCon, there was general agreement that exposing a read- only amk Bazaar/Mercurial/git/whatever version of the repository wouldn't be amk too much effort, and might make things easier for external people amk developing patches. I'm not much of a version control wonk. How would these help? Can't the folks who need such stuff do some sort of anonymous svn checkout? The version management systemens mentioned are distributed systems and would allow users to have local branches, which could mak development easier for them. They can already do this using SVK, which is a distributed version control system as well but uses SVN repositories to store its data. Ronald ___ 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
