
Hello! After a long time of inactivity, I hope to be back to some python hacking. Before getting into any coding, I'd like to discuss with you some conceptual and boring stuff I have in my mind. In the past I have given small contributions to the python standard distribution. Unfortunately (for myself), I slowed down until I stopped contributing, even though I have a great affect by the interpreter. Now I realize that one of the reasons I've stopped contributing is because there's a large inertia in getting stuff reviewed. The reason why this is happening seems more aparent now that I was off for a while: there's a small core of very busy developers working on core/essential/hard stuff *and* in code reviewing as well. At the same time, I've seen Guido and others bothered a few times because of the lack of man power. So the question is: how do I, a developer which feels capable of helping in python's development, can get some of the tasks which take your time out of your hands? Or even, how is it possible to improve some part of the development process by giving people like me some instructions? Also, isn't it easy to point out what's wrong in a commit from someone who is following the development process for a while than taking the time to review its code in the sourceforge patch system? My feeling is that the Python development is currently overly centralized, and that you might be suffering from that now, by being unable to handover some of your tasks to someone else. I feel that everytime I send a patch, besides being contributing, I'm also overloading you with more stuff to review and comment and etc. Perhaps the fallback costs for some wrong commit is too high now (did I heard someone mentioning subversion?)?! Could someone please discuss that issues with me, and perhaps just kick me away saying that I'm crazy? :-) -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

Gustavo Niemeyer <niemeyer@conectiva.com> writes:
To me, the most important aspect I'd like to hand off is the review of patches; to Tim, it is the analysis of bug reports. There is an ever-growing backlog of both of these (atleast for patches, we are in the state where just less than 100 are pending, so it's not that badly growing). It is clearly unsatisfying for submitters of both patches and bug reports if they don't hear anything. While some of these issues are tricky and require expertise not everybody might have, I'd still like to see more people getting involved with that. For reviewing of patches, I'd suggest the following guidelines: - start with the oldest patches, and work forward to the more recent ones (the most recent ones are regularly checked by several people, and applied or rejected if a quick decision is possible - but some of these slip through) - for each patch, try to find out if it a) is present (if not, post a notice saying that the upload is missing), b) applies to the Python source code cleanly (if not, either update the patch yourself, or request that the submitter does that), c) does what it says it does (no detailed analysis necessary yet) (if it is not clear what the patch does, or how it does that, request clarification); d) is appropriate for inclusion, by comparison to other features that are already in Python (if not, ask submitter for a rationale why this patch should be included, pointing out your objections), e) has undesirable side effects (if yes, ask the submitter for an evaluation why these side effects are acceptable), f) is complete (new features need documentation, bug fixes need regression test cases if possible), g) is correct: try compiling it to see whether it works, try to come up with boundary cases to see whether it still works, inspect it to see if you find any flaws... - if you find problems with the patch, post a note asking for correction. If you find there is already a note and the submitter hasn't acted for quite some time (10% of the entire life of the patch on SF), set a deadline at which time it will be rejected. If there is already a commentary from the submitter, re-perform the entire analysis. - If you find that you are not qualified to review the patch, still try to perform as many steps as you can. Don't hesitate to ask the submitter to explain things to you that you don't understand. - If you complete evaluation, propose rejection or acceptance. From time to time, post a list of patches that you think we should act upon. If I find your analysis convincing, I'll execute the proposed action quickly. For bug reports, a similar procedure applies. Check: - if the bug report is reproducable, - whether this is a bug at all, or perhaps a misunderstanding on the part of the submitter, and the documentation clearly says otherwise, - if there is a patch included, analyse the patch, - if there is no patch, but you can see how the bug would be fixed, ask the submitter (politely) whether he would like to write a patch, - see whether you can write a patch yourself. If you can't create a patch, dealing with a bug report might be tricky. If you can see a solution, but can't work on it, post your analysis into the bug report. If you think the bug is unfixable, explain this as well. If fixing the bug requires expertise that you know has, ask the submitter of who might have this expertise (especially when it comes to strange systems).
I'm not sure what you are proposing here? That all patches are just applied, and then backed-out if incorrect? While this may be appropriate sometimes, I think it would cause to many disturbances. It happens from time to time that people reading python-checkins find problems by inspection. More often, they find problems some time afterwards, because of unexpected side effects. This is a good thing, and it is possible only because the patches had been reviewed carefully on SF.
I agree with your first observation, but disagree with the second: there are plenty of tasks that could be handed over. There are just no volunteers to perform these tasks.
It's not that. Patches *must* be reviewed, or else they would be just incomplete: people might commit the patch, but fail to commit the documentation. Then, for a couple of years, there would be no documentation. Likewise for test cases. That the patch works is alone not good enough. It is time-consuming to produce high-quality software. However, that should not alone be a reason to give up the high standards of Python development. Regards, Martin

Martin v. Loewis wrote:
I think that the current assignment solution causes much of the delays we are seeing + python-devs are pretty busy these days with other stuff (needed for pizza and beer). I for one wouldn't mind if other developers with some time at hand jump in on already assigned patches and bug reports to help out. Martin does this on a regular basis and I find it really helps. Another strategy would be for developers to take over maintenance of certain parts of the code. We should then probably have a list of maintainers for the various parts on the patch submission list to make the assignment process easier for the submitting parties. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

That looks interesting. For an example of a project using a similar strategy, have a look at Subversion: http://svn.collab.net/repos/svn/trunk/COMMITTERS -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

"M.-A. Lemburg" <mal@lemburg.com> writes:
I personally don't see assignments as a fixed thing. I think developers who cannot process assigned tracker items should unassign themselves - I personally assign things for myself only if I know I can process them in the near future. I also think that people should not consider assigned items as "solved". If they had been assigned quite some time ago, people should indeed contribute if they can.
I don't really think this would work. I quite dislike the idea of somebody being "responsible" for some area of the code, being able to overrule his peers merely by his position - except for the BDFL, of course. Regards, Martin

On vrijdag, november 1, 2002, at 09:53 , Martin v. Loewis wrote:
I think that part of the problem is that large areas *are* de-facto controlled by one person (or, at best, a few people). If the word "Unicode" shows up I expectantly start looking in your or MAL's direction. Likewise, if "Macintosh" appears everyone starts staring at me. And the areas that don't have a clear champion either get ignored, or passed on to Guido, or picked up by yourself or Michael or one of the very few other people who do general firefighting. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

Jack Jansen <Jack.Jansen@oratrix.com> writes:
And there is nothing wrong with that. However, I would not want to formalize this any more: in principle, it should be possible for anybody to who as an OS X box to step in and validate a certain OS X patch. Given the various compile farms, really anybody could help. Of course, the regular contributors may not have the time to obtain the expert knowledge just to validate a single patch. However, I would sure hope that new contributors become experts on areas on which we already have one. Regards, Martin

On Sunday, Nov 3, 2002, at 09:14 Europe/Amsterdam, Martin v. Loewis wrote:
What I intended to say was almost the opposite of how it came out (apparently). Because certain areas are deemed the responsibility of certain people the other developers tend to use their SEP field on them. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

Jack Jansen <Jack.Jansen@cwi.nl> writes:
It's a different aspect of the same problem :-) If you think you have patches or bug reports assigned that you cannot process (either because of lack of knowledge, or lack of time), I think you should unassign them from yourself. This gives people looking at these things, and the submitter, a much better picture of the likelyness of an upcoming solution. Regards, Martin

It is clearly unsatisfying for submitters of both patches and bug reports if they don't hear anything. While some of these issues are
Indeed.
tricky and require expertise not everybody might have, I'd still like to see more people getting involved with that.
I see..
Thank you very much for your detailed descriptions. It will be a great reference for myself and for others which feel in the same situation. I'll try to understand the whole process and follow your instructions.
Not at all. I meant that people who prove to understand the basic development strategy, and also provided correct working and non-breaking patches, could get commit access more easily. I've read somewhere once something which I took for the projects I currently maintain. To decide if you should give someone commit access, it's not important if that person can produce pages of complex code, but if that person usually provide patches which follow the general strategy, and don't break anything.
I'm not suggesting by any means that the current system should be dropped, as stated above. OTOH, perhaps if we can improve the reviewing process somehow, even that wouldn't be important anymore.
Here! Here! :-) Sometimes there's just no obvious open door for people to get in.
That's a failure in the process, which can easily be reviewed in a post-commit fashion. If somebody fail to provide tests/documentation, drop them a line asking for it before anything else. If they still don't want to provide it, cut them out.
Fully agreed. And I don't want to contribute to reduce the standards in any way. Thank you very much! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

Gustavo Niemeyer <niemeyer@conectiva.com> writes:
That procedure is already in place: If you want commit privileges, just step forward and say that you want. In the past, Guido has set a policy that people who's commit privilege is fresh will still have to use SF, but can perform the checkin themselves.
Yes, that's the strategy I apply when reviewing patches: If the submitter wants it, and I can't find problems, I'll accept the patch ("problems" being studied widely, of course).
I've been contributing to GCC for a while, and I can tell you from first-hand experience that this won't work. If you don't make documentation a commit prerequisite, you never get it. Shutting out the contributor won't work, since they a) may still provide valuable contributions, and b) will tell you that they will get to provide the missing pieces RSN - which then of course never happens. Regards, Martin

<niemeyer steps forward>
policy that people who's commit privilege is fresh will still have to use SF, but can perform the checkin themselves.
That's ok with me. I think that besides that being the case for people who's just got commit access, any serious developer will submit a patch for review whenever he's not sure about something.
Ouch.. :-( Thanks again Martin! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

Martin v. Loewis wrote:
There aren't enough volunteers willing to dedicate a lot of time, but I bet there's a large group of people like me who do things like submitting an occasional patch of bug report. My interpretation of the problem Gustavo is pointing out is that the larger group really ins't able to help, because everything we do places an additional burden on the core developers. If more of these people were able to contribute directly (i.e. via CVS commit access), you'd get a double benefit, since they'd get their contributions in faster and it would help free up the core developers from a lot of busy work. I think people with CVS access would also be a lot more motivated to contribute, since it removes the uncertaintly about whether their work will go into the release or just be wasted. My solution is: 1. Post Martin's guidelines on how to help very prominently. 2. Offer CVS access to developers who submit useful patches. 3. Publicize #2 to promote more patches from people wanting to prove themselves. I'm proposing to set the bar pretty low for CVS access, but I think this is a good strategy overall. As long as people are aware of the standards they're expected to hold up and the trust they're being given, most of them will do their best not to abuse it. The cost of granting commit access to the wrong person is fairly low (just back out their changes and revoke their access), but granting access to the right person could pay off for many years. Ok, I'll quit trying to sound so important now :) jw

John Williams <jrw@pobox.com> writes:
I don't think this is the case. If you manage to fix a bug per week, and there are ten of you, we can make quite some progress within a few months. If those regular contributors know how to prepare a contribution to fit the formal requirements, and provide rationale and explanations, patches can be applied quite quickly.
It is my impression that all people who want CVS write access already have it (with Gustavo perhaps being one of a few exceptions).
2. Offer CVS access to developers who submit useful patches.
That may not be known - but we already do that.
3. Publicize #2 to promote more patches from people wanting to prove themselves.
Not sure whether this helps: people should not produce a burst of patches just to get commit privileges. Instead, they should contribute patches steadily (and should have done so in the past), and then get CVS write access as a simplification for the rest of the maintainers.
I'm proposing to set the bar pretty low for CVS access, but I think this is a good strategy overall.
I would expect that this will lead to quite a large committer list, with many people running away after some time. Regards, Martin

Hello Martin, On Fri, Nov 01, 2002 at 10:09:43PM +0100, Martin v. Loewis wrote:
It is my impression that all people who want CVS write access already have it (with Gustavo perhaps being one of a few exceptions).
If I may step in here -- let describe my own position, as I feel it might be shared by a number of bystanders. I have submitted a couple of bugs and patches, and am getting some sense of what is expected. I often run into pending patches and bugs that I'd like to help review, some that I even feel I could accept or reject (according to your guidelines), but I'm not sure I should be trusted CVS access right now. What about adding an SF outcome/resolution status ("reviewed" or "proposedly closed" or even "low-hanging fruit" :-) meaning that the issue has been reviewed and discussed, according to the guidelines, and that the reviewer thinks the item should now be closed (commited or rejected) ? I feel it is a better solution than just assigning the item to an arbitrary core developer. This lets anyone step in as a reviewer, which is a status that should be clearly documented: review other people's work and not your own, of course, and closely follow the guidelines. (SF might get in the way if it disallows third-parties to change an issue's outcome or resolution status; reviewers could instead use an inline keyword or ask the author to change the status.) Armin

On Sat, Nov 02, 2002 at 04:40:34PM -0800, Armin Rigo wrote:
I hope everyone feels welcome to make comments already. I'm not sure how SF works, but comments by others are helpful. Also, it would be great if people provided patches to existing bugs. Unfortunately, it's pretty obscure if the patch is added to the bug report. However, if a separate patch is added, it is likely to be seen/fixed sooner rather than later. For now, if anyone wants to make a comment on a bug proposing a patch or solution or more info and wants to make sure it's seen, add your comment and assign it to me (nnorwitz). I'd love to see the bugs brought down. Neal

Armin Rigo <arigo@tunes.org> writes:
I would hope the majority of Python contributors is in your position. It's not necessarily a matter of trust, but perhaps also of obligation: Many people contribute to a number of projects, as they use these projects in their (possibly paid) work, or else feel attracted to these projects - yet they would not consider them core contributors. Contributing to other projects in this way myself, I *like* not having to worry about CVS, and committing changes, etc.
Unfortunately, adding a Status field is not possible on SF. However, if you add a comment in this respect to the bug report, many people will see your comment. If you think someone should really act on a report, don't hesitate to post to python-dev.
I feel it is a better solution than just assigning the item to an arbitrary core developer.
Indeed. Leaving those unassigned would be best. The core developer can then assign the item, just to avoid duplication of efforts.
I usually phrase this as a recommendation: "I recommend to approve this patch", or some such. When rejecting patches, this has the additional benefit of giving the contributor a chance to revise the patch, or point out potential misunderstandings, before it gets closed. Regards, Martin

Gustavo Niemeyer <niemeyer@conectiva.com> writes:
To me, the most important aspect I'd like to hand off is the review of patches; to Tim, it is the analysis of bug reports. There is an ever-growing backlog of both of these (atleast for patches, we are in the state where just less than 100 are pending, so it's not that badly growing). It is clearly unsatisfying for submitters of both patches and bug reports if they don't hear anything. While some of these issues are tricky and require expertise not everybody might have, I'd still like to see more people getting involved with that. For reviewing of patches, I'd suggest the following guidelines: - start with the oldest patches, and work forward to the more recent ones (the most recent ones are regularly checked by several people, and applied or rejected if a quick decision is possible - but some of these slip through) - for each patch, try to find out if it a) is present (if not, post a notice saying that the upload is missing), b) applies to the Python source code cleanly (if not, either update the patch yourself, or request that the submitter does that), c) does what it says it does (no detailed analysis necessary yet) (if it is not clear what the patch does, or how it does that, request clarification); d) is appropriate for inclusion, by comparison to other features that are already in Python (if not, ask submitter for a rationale why this patch should be included, pointing out your objections), e) has undesirable side effects (if yes, ask the submitter for an evaluation why these side effects are acceptable), f) is complete (new features need documentation, bug fixes need regression test cases if possible), g) is correct: try compiling it to see whether it works, try to come up with boundary cases to see whether it still works, inspect it to see if you find any flaws... - if you find problems with the patch, post a note asking for correction. If you find there is already a note and the submitter hasn't acted for quite some time (10% of the entire life of the patch on SF), set a deadline at which time it will be rejected. If there is already a commentary from the submitter, re-perform the entire analysis. - If you find that you are not qualified to review the patch, still try to perform as many steps as you can. Don't hesitate to ask the submitter to explain things to you that you don't understand. - If you complete evaluation, propose rejection or acceptance. From time to time, post a list of patches that you think we should act upon. If I find your analysis convincing, I'll execute the proposed action quickly. For bug reports, a similar procedure applies. Check: - if the bug report is reproducable, - whether this is a bug at all, or perhaps a misunderstanding on the part of the submitter, and the documentation clearly says otherwise, - if there is a patch included, analyse the patch, - if there is no patch, but you can see how the bug would be fixed, ask the submitter (politely) whether he would like to write a patch, - see whether you can write a patch yourself. If you can't create a patch, dealing with a bug report might be tricky. If you can see a solution, but can't work on it, post your analysis into the bug report. If you think the bug is unfixable, explain this as well. If fixing the bug requires expertise that you know has, ask the submitter of who might have this expertise (especially when it comes to strange systems).
I'm not sure what you are proposing here? That all patches are just applied, and then backed-out if incorrect? While this may be appropriate sometimes, I think it would cause to many disturbances. It happens from time to time that people reading python-checkins find problems by inspection. More often, they find problems some time afterwards, because of unexpected side effects. This is a good thing, and it is possible only because the patches had been reviewed carefully on SF.
I agree with your first observation, but disagree with the second: there are plenty of tasks that could be handed over. There are just no volunteers to perform these tasks.
It's not that. Patches *must* be reviewed, or else they would be just incomplete: people might commit the patch, but fail to commit the documentation. Then, for a couple of years, there would be no documentation. Likewise for test cases. That the patch works is alone not good enough. It is time-consuming to produce high-quality software. However, that should not alone be a reason to give up the high standards of Python development. Regards, Martin

Martin v. Loewis wrote:
I think that the current assignment solution causes much of the delays we are seeing + python-devs are pretty busy these days with other stuff (needed for pizza and beer). I for one wouldn't mind if other developers with some time at hand jump in on already assigned patches and bug reports to help out. Martin does this on a regular basis and I find it really helps. Another strategy would be for developers to take over maintenance of certain parts of the code. We should then probably have a list of maintainers for the various parts on the patch submission list to make the assignment process easier for the submitting parties. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

That looks interesting. For an example of a project using a similar strategy, have a look at Subversion: http://svn.collab.net/repos/svn/trunk/COMMITTERS -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

"M.-A. Lemburg" <mal@lemburg.com> writes:
I personally don't see assignments as a fixed thing. I think developers who cannot process assigned tracker items should unassign themselves - I personally assign things for myself only if I know I can process them in the near future. I also think that people should not consider assigned items as "solved". If they had been assigned quite some time ago, people should indeed contribute if they can.
I don't really think this would work. I quite dislike the idea of somebody being "responsible" for some area of the code, being able to overrule his peers merely by his position - except for the BDFL, of course. Regards, Martin

On vrijdag, november 1, 2002, at 09:53 , Martin v. Loewis wrote:
I think that part of the problem is that large areas *are* de-facto controlled by one person (or, at best, a few people). If the word "Unicode" shows up I expectantly start looking in your or MAL's direction. Likewise, if "Macintosh" appears everyone starts staring at me. And the areas that don't have a clear champion either get ignored, or passed on to Guido, or picked up by yourself or Michael or one of the very few other people who do general firefighting. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

Jack Jansen <Jack.Jansen@oratrix.com> writes:
And there is nothing wrong with that. However, I would not want to formalize this any more: in principle, it should be possible for anybody to who as an OS X box to step in and validate a certain OS X patch. Given the various compile farms, really anybody could help. Of course, the regular contributors may not have the time to obtain the expert knowledge just to validate a single patch. However, I would sure hope that new contributors become experts on areas on which we already have one. Regards, Martin

On Sunday, Nov 3, 2002, at 09:14 Europe/Amsterdam, Martin v. Loewis wrote:
What I intended to say was almost the opposite of how it came out (apparently). Because certain areas are deemed the responsibility of certain people the other developers tend to use their SEP field on them. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

Jack Jansen <Jack.Jansen@cwi.nl> writes:
It's a different aspect of the same problem :-) If you think you have patches or bug reports assigned that you cannot process (either because of lack of knowledge, or lack of time), I think you should unassign them from yourself. This gives people looking at these things, and the submitter, a much better picture of the likelyness of an upcoming solution. Regards, Martin

It is clearly unsatisfying for submitters of both patches and bug reports if they don't hear anything. While some of these issues are
Indeed.
tricky and require expertise not everybody might have, I'd still like to see more people getting involved with that.
I see..
Thank you very much for your detailed descriptions. It will be a great reference for myself and for others which feel in the same situation. I'll try to understand the whole process and follow your instructions.
Not at all. I meant that people who prove to understand the basic development strategy, and also provided correct working and non-breaking patches, could get commit access more easily. I've read somewhere once something which I took for the projects I currently maintain. To decide if you should give someone commit access, it's not important if that person can produce pages of complex code, but if that person usually provide patches which follow the general strategy, and don't break anything.
I'm not suggesting by any means that the current system should be dropped, as stated above. OTOH, perhaps if we can improve the reviewing process somehow, even that wouldn't be important anymore.
Here! Here! :-) Sometimes there's just no obvious open door for people to get in.
That's a failure in the process, which can easily be reviewed in a post-commit fashion. If somebody fail to provide tests/documentation, drop them a line asking for it before anything else. If they still don't want to provide it, cut them out.
Fully agreed. And I don't want to contribute to reduce the standards in any way. Thank you very much! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

Gustavo Niemeyer <niemeyer@conectiva.com> writes:
That procedure is already in place: If you want commit privileges, just step forward and say that you want. In the past, Guido has set a policy that people who's commit privilege is fresh will still have to use SF, but can perform the checkin themselves.
Yes, that's the strategy I apply when reviewing patches: If the submitter wants it, and I can't find problems, I'll accept the patch ("problems" being studied widely, of course).
I've been contributing to GCC for a while, and I can tell you from first-hand experience that this won't work. If you don't make documentation a commit prerequisite, you never get it. Shutting out the contributor won't work, since they a) may still provide valuable contributions, and b) will tell you that they will get to provide the missing pieces RSN - which then of course never happens. Regards, Martin

<niemeyer steps forward>
policy that people who's commit privilege is fresh will still have to use SF, but can perform the checkin themselves.
That's ok with me. I think that besides that being the case for people who's just got commit access, any serious developer will submit a patch for review whenever he's not sure about something.
Ouch.. :-( Thanks again Martin! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

Martin v. Loewis wrote:
There aren't enough volunteers willing to dedicate a lot of time, but I bet there's a large group of people like me who do things like submitting an occasional patch of bug report. My interpretation of the problem Gustavo is pointing out is that the larger group really ins't able to help, because everything we do places an additional burden on the core developers. If more of these people were able to contribute directly (i.e. via CVS commit access), you'd get a double benefit, since they'd get their contributions in faster and it would help free up the core developers from a lot of busy work. I think people with CVS access would also be a lot more motivated to contribute, since it removes the uncertaintly about whether their work will go into the release or just be wasted. My solution is: 1. Post Martin's guidelines on how to help very prominently. 2. Offer CVS access to developers who submit useful patches. 3. Publicize #2 to promote more patches from people wanting to prove themselves. I'm proposing to set the bar pretty low for CVS access, but I think this is a good strategy overall. As long as people are aware of the standards they're expected to hold up and the trust they're being given, most of them will do their best not to abuse it. The cost of granting commit access to the wrong person is fairly low (just back out their changes and revoke their access), but granting access to the right person could pay off for many years. Ok, I'll quit trying to sound so important now :) jw

John Williams <jrw@pobox.com> writes:
I don't think this is the case. If you manage to fix a bug per week, and there are ten of you, we can make quite some progress within a few months. If those regular contributors know how to prepare a contribution to fit the formal requirements, and provide rationale and explanations, patches can be applied quite quickly.
It is my impression that all people who want CVS write access already have it (with Gustavo perhaps being one of a few exceptions).
2. Offer CVS access to developers who submit useful patches.
That may not be known - but we already do that.
3. Publicize #2 to promote more patches from people wanting to prove themselves.
Not sure whether this helps: people should not produce a burst of patches just to get commit privileges. Instead, they should contribute patches steadily (and should have done so in the past), and then get CVS write access as a simplification for the rest of the maintainers.
I'm proposing to set the bar pretty low for CVS access, but I think this is a good strategy overall.
I would expect that this will lead to quite a large committer list, with many people running away after some time. Regards, Martin

Hello Martin, On Fri, Nov 01, 2002 at 10:09:43PM +0100, Martin v. Loewis wrote:
It is my impression that all people who want CVS write access already have it (with Gustavo perhaps being one of a few exceptions).
If I may step in here -- let describe my own position, as I feel it might be shared by a number of bystanders. I have submitted a couple of bugs and patches, and am getting some sense of what is expected. I often run into pending patches and bugs that I'd like to help review, some that I even feel I could accept or reject (according to your guidelines), but I'm not sure I should be trusted CVS access right now. What about adding an SF outcome/resolution status ("reviewed" or "proposedly closed" or even "low-hanging fruit" :-) meaning that the issue has been reviewed and discussed, according to the guidelines, and that the reviewer thinks the item should now be closed (commited or rejected) ? I feel it is a better solution than just assigning the item to an arbitrary core developer. This lets anyone step in as a reviewer, which is a status that should be clearly documented: review other people's work and not your own, of course, and closely follow the guidelines. (SF might get in the way if it disallows third-parties to change an issue's outcome or resolution status; reviewers could instead use an inline keyword or ask the author to change the status.) Armin

On Sat, Nov 02, 2002 at 04:40:34PM -0800, Armin Rigo wrote:
I hope everyone feels welcome to make comments already. I'm not sure how SF works, but comments by others are helpful. Also, it would be great if people provided patches to existing bugs. Unfortunately, it's pretty obscure if the patch is added to the bug report. However, if a separate patch is added, it is likely to be seen/fixed sooner rather than later. For now, if anyone wants to make a comment on a bug proposing a patch or solution or more info and wants to make sure it's seen, add your comment and assign it to me (nnorwitz). I'd love to see the bugs brought down. Neal

Armin Rigo <arigo@tunes.org> writes:
I would hope the majority of Python contributors is in your position. It's not necessarily a matter of trust, but perhaps also of obligation: Many people contribute to a number of projects, as they use these projects in their (possibly paid) work, or else feel attracted to these projects - yet they would not consider them core contributors. Contributing to other projects in this way myself, I *like* not having to worry about CVS, and committing changes, etc.
Unfortunately, adding a Status field is not possible on SF. However, if you add a comment in this respect to the bug report, many people will see your comment. If you think someone should really act on a report, don't hesitate to post to python-dev.
I feel it is a better solution than just assigning the item to an arbitrary core developer.
Indeed. Leaving those unassigned would be best. The core developer can then assign the item, just to avoid duplication of efforts.
I usually phrase this as a recommendation: "I recommend to approve this patch", or some such. When rejecting patches, this has the additional benefit of giving the contributor a chance to revise the patch, or point out potential misunderstandings, before it gets closed. Regards, Martin
participants (8)
-
Armin Rigo
-
Gustavo Niemeyer
-
Jack Jansen
-
Jack Jansen
-
John Williams
-
M.-A. Lemburg
-
martin@v.loewis.de
-
Neal Norwitz