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