Date: Thu, 08 Feb 1996 10:14:03 -0800 From: Paul Traina <pst@shockwave.com> To: committers@freebsd.org Cc: freebsd-bugs@freebsd.org Subject: What's up with bug assignments? (please read) Message-ID: <199602081814.KAA04730@precipice.shockwave.com>
next in thread | raw e-mail | index | archive | help
A while back, I spoke with several people about bug assignments, and Jordan asked me to play bug czar to clean out our backlog. We've got a ton of bug reports, most of them are ancient history and simply need to be closed. I don't have complete knoweldge of every fix applied, so I'm passing them along to other folks to act as responsible parties. ---- Finding Bugs ---- The current bug list: http://www.freebsd.org/cgi-bin/query-pr-summary.cgi Find all bugs assigned to pst: http://www.freebsd.org/cgi-bin/query-pr-summary.cgi?engineer=pst List all assigned bugs and whom they're assigned to: http://www.freebsd.org/cgi-bin/query-pr-summary.cgi?engineer=summary Find all bugs in state feedback: http://www.freebsd.org/cgi-bin/query-pr-summary.cgi?state=feedback ---- Bug states ---- open A bug report has been submitted. analyzed Someone from our group has verified the problem and/or added suggestions for fixing it. feedback A fix has been *committed* to the repository (and, if necessary, patches sent to the user) we're awaiting feedback to insure the fix does the job. Do not use this state if the repository isn't fixed closed A fix has been *committed* to the repository OR, we will not be doing anything with this bug report. (duplicate) If you come across a bug report that is a duplicate of another report, you may choose to close it. The reason for closing it should be "Duplicate of xxxx/###" ---- Bug triage ---- You can edit a bug report using the "edit-pr" program. There's no man-page currently, but the program-use is pretty obvious. Pull down the current bug list: * Has something been fixed? Close it, the reason is: "Fixed." * Is a bug report bogus? Close it, explain why in a sentence. * Is the bug "open" but not "analyzed" ? Can you contribute an analysis? * Is this bug in your area of expertise? Assign it to yourself or the person you feel most appropriate. ---- Bug assignments ---- Bugs assigned to freebsd-bugs are not assigned to anyone. Bugs not assigned to anyone will be assigned, by me, to the person who I think is responsible for a particular area of code. This is an entirely subjective process on my part (well, I do some research on each bug). If you think I screwed up, please take responsibility for getting the bug to the right person. I'm not perfect. There will be times when I assign a bug to an individual because I think they can make a better choice of assigning it to the proper owner. (For instance, davidg gets most generic VM related problems because he can triage them and keep or send them on to dyson/bde/nate et al). You may assign bugs back to "freebsd-bugs" as a last-ditch effort, however you then cause everyone to re-triage the bug from the start. It's far better to assign a bug to the proper person. Anyone is welcome to assign bugs. In fact, it would be best if certain folks would step forward and assign bugs for an entire area of code (e.g. wollman could become bug czar for all networking related code). ---- Kiss of death ---- There is _no_ excuse for sitting on a bug that you don't/can't/won't fix. Either assign it to the proper person, or send me e-mail and I will work out what to do. Sitting on a bug in silence will earn you negative karma points from all FreeBSD team members. Yes, I know we're all volenteers here (so am I). I'd like to thank you all in advance for putting up with this little bit of bullshit so that we can help make the most usable OS in town. Thanks for your understanding, Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602081814.KAA04730>