[Python-Dev] Buglist (original) (raw)

Thomas Wouters thomas@xs4all.net
Thu, 3 Aug 2000 16:49:49 +0200

On Thu, Aug 03, 2000 at 10:14:13AM -0400, Jeremy Hylton wrote:

In principle, it's okay to mark bugs as closed, as long as you are sure that the bug has been fixed. If you try to reproduce a bug on your system and can't, it's not clear that it has been fixed. It might be a platform-specific bug, for example. I would prefer it if you only closed bugs where you can point to the CVS checkin that fixed it.

This is tricky for some bugreports, as they don't say anything about the platform in question. However, I have been conservative, and haven't done anything if I didn't either have the same platform as mentioned and could reproduce the bug with 1.6a2 and/or Python 1.5.2 (very handy to have them lying around) but not with current CVS, OR could find the CVS checkin that fixed them. For instance, the incorrect usage of PyMem_Del() in some modules (bug #110638) seems to be fixed, but I can't really test it and the CVS checkin(s) that seem to fix it don't even mention the bug or the reason for the change.

Whenever you fix a bug, you should add a test case to the regression test that would have caught the bug. Have you done that for any of the bugs you've marked as closed?

No, because all the bugs I've closed so far are 'obviously fixed', by someone other than me. I would write one if I fixed the bug myself, I guess. Also, most of these are more 'issues' rather than 'bugs', like someone complaining about installing Python without Tcl/Tk and Tkinter not working, threads misbehaving on some systems (didn't close that one, just added a remark), etc.

You should also add a comment at any bug you're closing explaining why it is closed.

Of course. I also forward the SF excerpt to the original submittor, since they are not likely to browse the SF buglist and spot their own bug.

It is good to assign bugs to people -- probably even if we end up playing hot potato for a while. If a bug is assigned to you, you should either try to fix it, diagnose it, or assign it to someone else.

Hm, I did that for a few, but it's not very easy to find the right person, in some cases. Bugs in the 're' module, should they go to amk or to /F ? XML stuff, should it go to Paul Prescod or some of the other people who seem to be doing something with XML ? A 'capabilities' list would be pretty neat!

> I think overlooking a few bugs is better than overlooking all of > them because of the size of the list :P

You seem to be arguing that the sheer number of bug reports bothers you and that it's better to have a shorter list of bugs regardless of whether they're actually fixed. Come on! I don't want to overlook any bugs.

No, that wasn't what I meant :P It's just that some bugs are vague, and seem fixed, but are still an issue on some combination of compiler, libraries, OS, etc. Also, there is the question on whether something is a bug or a feature, or an artifact of compiler, library or design. A quick pass over the bugs will either have to draw a firm line somewhere, or keep most of the bugs and hope someone will look at them.

Having 9 out of 10 bugs waiting in the buglist without anyone looking at them because it's too vague and everyone thinks not 'their' field of expertise and expect someone else to look at them, defeats the purpose of the buglist. But closing those bugreports, explaining the problem and even forwarding the excerpt to the submittor might result in the original submittor, who still has the bug, to forget about explaining it further, whereas a couple of hours trying to duplicate the bug might locate it. I personally just wouldn't want to be the one doing all that effort ;)

Just-trying-to-help-you-do-your-job---not-taking-it-over-ly y'rs,

Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!