[Python-Dev] I would like an svn account

[Victor Stinner]

Le Wednesday 31 December 2008 08:46:09 Stephen J. Turnbull, vous avez écrit :
> Would you review your own code in the same way that other committers 
> review their own?

I'm unable to review my own code. I always re-read my code and test it, but I 
can not see every possibles cases. That's why I prefer external eyes to 
review my code for parts of the code that I don't understand/known well 
enough.

> 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?

I think that I'm able to know if a patch needs a review or not. Especially if 
the patch changes the behaviour or the API (or if the patch is complex), I 
always prefer a review.

I will not use svn as I use the tracker. Sometimes, I write a quick and dirty 
patch to demonstrate a feature or to propose a solution to fix the bug. If 
the solution is accepted, I try to write a better patch.

>  > 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?

Certainly not. The patch changed the behaviour of most functions related to 
files. The mailing list + the bug tracker were the right tools.

>  > 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?

It depends on the issue. There are many trivial fixes that doesn't change the 
behaviour / API but just improve the project and are waiting for a review or 
are reviewed but not commited yet.

About my own patch: yes, I would like to use direclty on the svn without using 
the tracker to fix trivial bugs. Example: during one month, there were two 
gcc warnings in _testcapi module. The fix was trivial and it requires too 
much efforts to open an issue for such stupid warning.

> 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.

My not-so-secret goal is also to improve Python stability against fuzzing. I 
stopped to work on fuzzing because it took sometimes months to fix a dummy 
bug (dummy : easy to understand but also easy to fix without side effects).

Example of such issue: "import _tkinter; _tkinter.mainloop()" crashs Python 
(maybe not directly but later on garbage collection). I opened the issue 
(with a patch) in august, gpolo reviewed the patch ("Looks fine to me.") two 
weeks later, but 4 months later the isue is still open:
   http://bugs.python.org/issue3638

Is it was you called "An open issue is not a lost patch."?

> 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.

Even after a review, some issues stay open for months or years.

Another example of issue: nntplib doesn't support IPv6, dmorr proposed a 
simple and good patch reusing the nice function socket.create_connection() 
one year ago. In this case, I think that nobody was able to test the change. 
But without testing it, I'm sure that the patch is better than the current 
situation. Well, if I have to commit the patch, I will test it before. My 
computer has a public IPv6 address :-)
   http://bugs.python.org/issue1664

> You don't have to pay attention to me,

No, your opinion is interresting. I hope that my answers will help you to 
understand my expectations about an svn account :-)

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/