> 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 ]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4