On Fri, Jan 2, 2009 at 18:53, Victor Stinner <victor.stinner@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