[Python-Dev] I would like an svn account

[Brett Cannon]

On Fri, Jan 2, 2009 at 18:53, Victor Stinner
<victor.stinner at haypocalc.com> wrote:
> Le Wednesday 31 December 2008 22:20:54, vous avez écrit :
>> When it comes to commit privs in general, I am of the school that they
>> should be handed out carefully. I for one do not want to have to
>> babysit other committers to make sure that they did something
>> correctly.
>
> Last time I asked if anyone could help me in Python core if I had an svn
> account, and I get this answer: everybody will review the changes. Anyway,
> why do you fear problems? Did I already push buggy commits? I posted many
> patches on Python bug tracker, most of them required many versions until they
> get perfect. But it doesn't mean that with an svn account, I will skip the
> bug tracker to wrote directly in the svn as my personal copy of Python!?
>

I know people will review your commits, but I prefer to have that be a
safety precaution than any feeling that it is really required.

And if you really do plan to continue to use the tracker heavily, that
does help alleviate this worry. Once you have the ability to check in
directly the temptation to skip having to wait for reviews becomes
rather strong.

>> I also want people who have no agenda. It's okay to have an area you
>> care about, but that doesn't mean you should necessarily say "I will
>> only work on math, ever, even if something is staring me right in the
>> face!", etc.
>
> I wrote that I would like to improve Python quality by fuzzing, but I already
> contributed to many different topics by patches on the bug tracker.
>
>> There is also dedication. I don't like giving commit privileges to
>> people who I don't think will definitely stick around. (...)
>
> I don't understand why this is a problem.
>

Because when people contribute large bodies of code and then disappear
someone then eventually has to step in and take up maintenance. That
means more stuff for someone to have to keep up with and having to
learn how the code works.

>> To start, your focus on security, for me at least, goes too
>> far sometimes. I have disagreed with some of your decisions in the
>> name of security in the past and I am not quite ready to say that if
>> you committed something I wouldn't feel compelled to double-check it
>> to make sure you didn't go too far.
>
> I'm not sure that I understood correclty: does it mean that some of my issues
> were not reproductible in the real world (far from the real usage of Python)?
> It's true that some issues found by fuzzing are hard to reproduce (require a
> prepared environment), but my goal is to kill all bugs :-) Even if the bug is
> hard to reproduce, it does exist and that's why I'm thinking that it should
> be fixed.
>
> Sorry if I misused the name "security" but I don't remember where I wrote
> that "this issue is very security and related to security". Maybe by the
> imageop issues?
>

What I mean is that I remember an instance or two where you found
something that seemed like a security issue but that is otherwise not
critical and wanting to make a change for it that I disagreed with
based on it being security-related. Python is basically secure, but we
have never claimed we are perfect. And I understand wanting to squash
all bugs, but there have to be priorities, and sometimes security is
not the highest priority for really obscure stuff. Or at least that's
my opinion.

> --
>
> About fuzzing: I'm still using my fuzzer Fusil on Python trunk and py3k, and I
> find fewer and fewer bugs ;-) Most of the time I rediscover bugs already
> reported to the tracker, but not fixed yet. So the fuzzing job is mostly
> done ;-)
>

That's good to hear!

As I said, you are on your way, but I personally just am not ready to
give you a +1 for commit privs. As Raymond said and you admitted to
above, your patches still go through several revisions. Having commit
privileges means you can skip that step and I am just not feeling
comfortable with that to happen yet.

But if another core developer or three are willing to say they will
act as probationary officers on ALL of your commits for a while and
you at least initially continue to use the issue tracker until the
people watching your commits are willing to say you don't need to be
watched, then I am fine with you getting commit privs.

And I hope everyone realizes that they can speak up (publicly or
privately) about *anyone* in regards to whether they think they need
to lose their commit privileges for personal or coding reasons. I know
it's tough to speak out publicly about someone and their coding
abilities which is why I am trying to rationalize this for Victor
instead of just sitting quietly while he does or does not get
responses from people on whether he should get commit privileges.
Every time commit privileges are given out it is a leap of faith and
sometime the leap comes up short.

-Brett