Victor Stinner writes:
I already asked in September to get an svn account to be able to commit directly patches to trunk (or other branches like py3k). My query was rejected because I didn't know Python core enough (and maybe other reasons that I don't know).
One possible reason is that commit privilege is not about quality of code, it's about quality of review. Would you review your own code in the same way that other committers review their own? Would you make the same decisions about which fixes to commit, which changes to wait for others' review, and which to propose on Python-Dev first? Remember, to be appropriate for Python, a patch needs not only to be good code, it must also be "Pythonic". Does your personal sense of code quality result in Pythonic patches? (I can't answer that, because my own sense of Pythonicity is dubiously reliable at best.<wink>)
Another possible reason is that, while it's not an absolute requirement, in my projects I'm always a lot more supportive of candidates who have a track record of helping others get their patches committed. Of course if your patches have a history of being accepted often without substantial change, then implicitly you are doing good self-review, and that might be enough. But in my book, that path should take longer and demand higher standards than the "review others' patches" path.
The bigger patch was the bytes filename support for Python3, accepted by Guido (after a long review ;-)).
Would you have committed that patch if nobody else had reviewed it?
Just because there are not enough people to review/commit patches on the tracker and
Are you planning to review and commit other people's patches, and help reduce this backlog? Or just your own? Your emphasis on your own working speed suggests the latter. Again, I'm more supportive of people who want commit privileges in part to help improve the project's process, as well as to remove obstacles to their own work.
so there are more and more open issues (and so more and more lost patches) :-(
An open issue is not a lost patch. It's an open issue. In my own projects, I oppose candidates who seem to think that the presumption is that a patch should be applied quickly unless there's good reason given not to. Your phrasing suggests that attitude to me.
You don't have to pay attention to me, since I don't have a vote in the matter. And I don't mean to be negatively critical of you, because I'm not in a position to speak for the Powers That Be in Python. Those are my criteria, and other people and projects use different ones. But it seems to me that the committers in Python do mostly conform to my criteria, and thus it's possible that those criteria are somewhat representative of the "maybe other reasons [you] don't know."
If so, I suppose an explicit explanation may be of use to you (and others in your position).
Happy New Year to you!