[Python-Dev] Buglist

[Thomas Wouters]

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!