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
Attachment:
signature.asc
Description: This is a digitally signed message part