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 ]