[Python-Dev] I would like an svn account

[Stephen J. Turnbull]

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!