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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
