Gustavo Niemeyer <niemeyer@conectiva.com> 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