Just a little FYI and 'is this okay' message; I've been browsing the buglist the last few days, doing a quick mark & message sweep over the bugs that I can understand. I've mostly been closing bugs that look closed, and assigning them when it's very obvious who it should be assigned to. Should I be doing this already ? Is the bug-importing 'done', or is Jeremy still busy with importing and fixing bug status (stati ?) and such ? Is there something better to use as a guideline than my 'best judgement' ? I think it's a good idea to 'resolve' most of the bugs on the list, because a lot of them are really non-issues or no-longer-issues, and the sheer size of the list prohibits a proper overview of the real issues :P However, it's entirely possible we're going to miss out on a few bugs this way. I'm trying my best to be careful, but I think overlooking a few bugs is better than overlooking all of them because of the size of the list :P -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
I am done moving old bugs from Jitterbug to SF. There are still some new bugs being submitted to Jitterbug, which I'll need to move one at a time. 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. 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? You should also add a comment at any bug you're closing explaining why it is closed. 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.
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. Jeremy
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!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
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.
TW> Hm, I did that for a few, but it's not very easy to find the TW> right person, in some cases. Bugs in the 're' module, should TW> they go to amk or to /F ? XML stuff, should it go to Paul TW> Prescod or some of the other people who seem to be doing TW> something with XML ? A 'capabilities' list would be pretty neat! I had the same problem when I was trying to assign bugs. It is seldom clear who should be assigned a bug. I have used two rules when processing open, uncategorized bugs: * If you have a reasonable guess about who to assign a bug to, it's better to assign to the wrong person than not to assign at all. If the wrong person gets it, she can assign it to someone else. * If you don't know who to assign it to, at least give it a category. That allows someone who feels expert in a category (e.g. a Tkinter guru), to easily scan all the unassigned bugs in that category.
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.
TW> No, that wasn't what I meant :P Sorry. I didn't believe you really meant that, but you came off sounding like you did :-). TW> Having 9 out of 10 bugs waiting in the buglist without anyone TW> looking at them because it's too vague and everyone thinks not TW> 'their' field of expertise and expect someone else to look at TW> them, defeats the purpose of the buglist. I still don't agree here. If you're not fairly certain about the bug, keep it on the list. I don't see too much harm in having vague, open bugs on the list. TW> But closing those TW> bugreports, explaining the problem and even forwarding the TW> excerpt to the submittor *might* result in the original TW> submittor, who still has the bug, to forget about explaining it TW> further, whereas a couple of hours trying to duplicate the bug TW> might locate it. I personally just wouldn't want to be the one TW> doing all that effort ;) You can send mail to the person who reported the bug and ask her for more details without closing it. TW> Just-trying-to-help-you-do-your-job---not-taking-it-over-ly And I appreciate the help!! The more bugs we have categorized or assigned, the better. of-course-actually-fixing-real-bugs-is-good-too-ly y'rs, Jeremy
participants (2)
-
Jeremy Hylton -
Thomas Wouters