On Tue, 2009-10-27 at 11:10 -0600, dann frazier wrote: [...] > > 2. Severities > > > > Many submitters believe that their bug meets one of the following > > criteria for high severity. We interpret them as follows and will > > downgrade as appropriate: > > Though infrequent, we do sometimes need to "upgrade" severities as > well. Maybe we can say "adjust as appropriate" vs. downgrade? I know > this section is about bloated severities, but it might work better as > a "here's how we interpret severities" section.
Agreed. [...] > > 3. Tagging > > > > We do not use user-tags, but in order to aid bug triage we should: > > > > * Add 'moreinfo' whenever we are waiting for a response from the > > submitter and remove it when we are not. > > * Add 'upstream', 'fixed-upstream', 'patch', 'help' where appropriate > > You could also add 'forwarded' to this list - though, you might also > be able to do away with this bullet and complete this section with > "other tags should be used as defined by the bug tracking system" > instead of calling out well-defined tags. I'll do that. > > * Not add 'unreproducible', since bugs are commonly hardware-dependent > > Though, sometimes bugs aren't hardware dependent - and unreproducible > makes sense. Maybe "Not add 'unreproducible' in cases where the bug > maybe hardware dependent"? Right. > > 5. Testing by submitter > > > > Depending on the technical sophistication of the submitter and the > > service requirements of the system in question (e.g. whether it's a > > production server) we can request one or more of the following: > > > > * Gathering more information passively (e.g. further logging, reporting > > contents of files in procfs or sysfs) > > * Upgrading to the current stable/stable-proposed-updates/ > > stable-security version, if it includes a fix for a similar bug > > * Adding debug or fallback options to the kernel command line or > > module parameters > > * Installing the unstable [or backports?] version temporarily > > * Rebuilding and installing the kernel with a specific patch added > > [I think we should add a script to the source to make this easier] > > > > When a bug occurs in what upstream considers the current or previous > > stable release, and we cannot fix it, we ask the submitter to report it > > upstream at bugzilla.kernel.org under a specific Product and Component, > > and to tell us the upstream bug number. We do not report bugs directly > > because follow-up questions from upstream need to go to the submitter, > > not to us. Given the upstream bug number, we mark the bug as forwarded. > > bts-link then updates its status. > > We tried to capture a lot of the common user-triage processes here: > http://wiki.debian.org/DebianKernelReportingBugs > > Maybe we could update that/reference it in this doc? I'll try to merge the two. > > 6. Keeping bugs separate > > > > Many submitters search for a characteristic error message and treat this > > as indicating a specific bug. This can lead to many 'me too' follow-ups > > where, for example, the message indicates a driver bug and the second > > submitter is using a different driver from the original submitter. We > > should try to respond to such a follow-up quickly, requesting a separate > > bug report. Otherwise the original report is likely to turn into a mess > > of conflicting information about two or more different bugs. > > > > Where the original report describes more than one bug ('...and other > > thing...'), we should clone it and deal with each separately. > > It might be valuable to just close any bugs that have gotten > confusing overtime and clone a new bug for each *real* issue described > within, with a good explanation that helps prevent confusion. > "JUST BECAUSE YOU ARE SEEING A SOFT LOCKUP DOES NOT MEAN THIS IS YOUR > BUG". [...] Another option may be to use the new 'summary' command <http://www.debian.org/Bugs/server-control#summary>. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett
signature.asc
Description: This is a digitally signed message part
