Date: Wed, 22 Mar 1995 02:53:07 -0600 (CST) From: Mike Pritchard <pritc003@maroon.tc.umn.edu> To: paul@isl.cf.ac.uk (Paul Richards) Cc: freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR kern/179 Message-ID: <199503220853.CAA01829@mpp.com> In-Reply-To: <199503220649.GAA01658@isl.cf.ac.uk> from "Paul Richards" at Mar 22, 95 06:49:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Many bug reports give only a special case of the bug. They should > > be edited by someone who understands all the details if the someone > > doesn't have time to fix all the details. > > > > This process should happen anyway. When a bug report arrives someone who > knows that code area should go and see what the cause of the problem is > and change the state to analysed, with an explanation of what the real > extent of the problem is. Then if necessary they can spend time thinking > about the correct way to fix it and if someone gets impatient and tries > a quick fix they should see that its already been analyzed and what exactly > would be involved to fix it. I agree with this. In the past I worked for a major Unix vendor, and this is similar to how we used to process incoming problem reports. Each bug report was assigned to a specific area by the user, and then by our front-line support people (kernel, compiler, networking, apps, etc...). Each member of those specific areas were expected to scan the bug reports every couple of days and assign anything that fell into their area of expertise to themselves. E.g. if I worked on xxx, and a bug report came in on xxx, I would usually go and assign the problem report to myself. Now, that didn't keep someone else from taking over the problem report from me. If they saw a problem report on xxx, and recognized it as a problem with zzz, they were free to take over the problem report after contacting me and letting me know. Likewise, if I saw a problem report in my area and from the description given by the user or after a little investigation I decided that it really should be assigned to another group, I was free to reassign the problem report to that group. Once in a while things did bounce back and forth until both groups fully understood the problem, but that didn't happen too often. The main thing is that even if someone has been assigned a bug, that doesn't keep anyone else from fixing it. Just as long as they let the other person know that so they don't keep working/thinking about it anymore. Another step that might be nice to see in the FreeBSD problem resolution process is some type of "verification" phase. There have been a lot of bug reports closed in the past few days that have had comments like "fixed", or "xxx says it is fixed". And then some mail saying "well, only 1 of those was really fixed..." Someone should really verify that these problems have really been fixed, esp. the ones that have been closed with "xxx says it is fixed". I know that there are not that many extra people to do this with everything, but if possible, the person who originally reported the problem should have a chance to test the new fix and report if it solves the problem or not. And one last thing, is it possible for joe user to see the open problem reports (other than the weekly summary we should all be getting now)? If not, that might be nice, along with someway to append a "me too" comment on existing problem reports.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503220853.CAA01829>