An invalidated bug. Should it have really been invalidated?

[Dr. David Alan Gilbert]

* C de-Avillez (hggdh2 at ubuntu.com) wrote:
> On Sun, 11 Aug 2013 06:13:09 +0100
> Phil Wyett <one.ukit at gmail.com> wrote:
> 
> > I have read the whole document now after not reading it for a few
> > years. It seems many changes and caveats have been introduced and now
> > we have many flaws in the whole bug reporting process. What should be
> > a simple process for new/inexperienced users (not me as a dev), has
> > actually turned into a spiders web of iffy software and processes to
> > perform the overall task with the addition of many 'do nots'
> > introduced by contributors.
> 
> Well. Let's keep in mind that bug reports are *technical* reports. On
> commercial systems, an end-user opens an incident, help-desk/L1-support
> looks at it and then -- if needed -- upgrades the incident to a bug
> (and involves L2/L3, as needed).
> 
> (my personal view is that end-users [1] should never directly open a
> bug.)

Well,  ok,  but we don't have a separate 'bug' and 'incident' system;
we've just got one; and I think I agree that's the real problem.

> So, yes, bugs processes have gotten more complex. But this is not an
> unneeded complexity, I hope (of course, as time goes by chaos creeps
> in, and we should review the processes every so often).
> 
> The crux here, to my understanding, is that end-users -- to say,
> non-expert, casual, users -- should NOT open a bug by hand.

Woah hang on, that's a separate problem - we're not talking about
bugs without suitable info are we? I thought this was from a 
discussion about where the original reporter had given up.

> (for example, there is one LP user that insists in manually opening
> his/her bugs, always against 'Ubuntu'. I gave up asking to use
> 'ubuntu-bug', and I now leave all his/her new bugs aside. Also, most of
> her/his bugs are actually user issues, not package/code bugs.)
> 
> Specifically for hardware-related bugs, the rules of thumb are: if you
> are not a developer/expert, (1) open a new bug; (2) use
> 'ubuntu-bug' to open the bug; (3) at most add a link to the existing
> bug you think may be related; (4) do NOT comment on other bugs.

Why (4)?  The fact is the devs aren't getting around to diagnosing
the contents of most of the bugs, especially hardware bugs, so it makes
sense for end users to help to try and find where they have other people
suffering from the same problem, and it often works well.

I think the problem here is that we don't have a defined mechanism at the
moment for anyone, including bugsquad/control/devs to create a way
to actually say these bugs are all the same thing, and that makes
sense when the original reporter walks away.

Spotting the patterns in related bugs is critical, it's where
we have chances to fix lots of things at once and spot really important
breakages.

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/