Gustavo Niemeyer writes:

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?

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).

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?

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.

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 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.

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?)?!

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

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..

For reviewing of patches, I'd suggest the following guidelines: [...] - 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: [...]

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.

...

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?

I'm not sure what you are proposing here? That all patches are just applied, and then backed-out if incorrect? [...]

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.

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'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.

...

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 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.

Here! Here! :-) Sometimes there's just no obvious open door for people to get in.

...

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?)?!

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.

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.

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.

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 ]

Martin v. Loewis wrote:

Gustavo Niemeyer writes:

...

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 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.

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

Gustavo Niemeyer writes:

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.

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.

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.

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).

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.

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

...

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.

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

<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.

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. [...]

Ouch.. :-( Thanks again Martin! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

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

Jack Jansen writes:

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 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

Neal Norwitz writes:

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.

I would also suggest that people indicate such patches in the title, e.g. "Fix for #foobar". I usually give such titles high priority, because it would allow to close two things simultaneously. Regards, Martin

Jack Jansen writes:

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.

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