An invalidated bug. Should it have really been invalidated?

[C de-Avillez]

On Wed, 14 Aug 2013 00:05:08 +0100
"Dr. David Alan Gilbert" <ubuntu at treblig.org> wrote:

> * Brian Murray (brian at ubuntu.com) wrote:
> > On Sat, Aug 10, 2013 at 05:44:31PM +0100, Dr. David Alan Gilbert
> > wrote:
> > > * Claudio Moretti (flyingstar16 at gmail.com) wrote:
> > > > On Sat, Aug 10, 2013 at 5:16 PM, Phil Wyett
> > > > <one.ukit at gmail.com> wrote:
> > > > 
> > > > > The bug I am concerned about is #1172908
> > > > >
> > > > 
> > > > I reopened it; in my opinion, it should have never been closed:
> > > > if there's at least one person able to reproduce it, the bug is
> > > > there. In this case, there are three.
> > > 
> > > I agree, however it's a little tricky with Kernel bugs; the normal
> > > instructions there are not to merge bugs unless you're sure it's
> > > the same bug.
> > > In this case I would agree they're almost certainly the same
> > > problem (since the models are all the same).
> > 
> > I didn't read all the comments in the bug report, but how can we be
> > certain that they are all the same models?  I'm under the impression
> > that internal components of systems change even though they may all
> > be called the same name.  Subsequently, I understand why the kernel
> > team wants individual bug reports (with hardware information
> > gathered) from each user.
> 
> I'm ok with requiring individual bugs from individual users
> but we've got to be able to do something when we find a bug
> that feels like it's specific and affects a certain range of machines.
> Can we be 'certain' no, but given that:
> 
>    - It's a specific well defined problem (Only the USB2 ports are
> failing not the USB3).
>    - We're not seeing this on loads of different systems
>    - But we are seeing it on a group of similar models 
>    - It's not a fluffy sometimes-happens bug.
> 
> Now some of those are a judgement call rather than a hard
> and fast rule, but that's why we're not entirely scripted!
> 
> Then I say we have a common bug here and we need some way to represent
> it.  If the way isn't allowing multiple users to put their info
> on one report then we need a metabug or something, we also
> need a way to keep hold of it if any one of the original reporters
> gives up.

I agree, and I think all would agree as well. This is where I stated,
in another subthread, that have a procedure to identify "collisions"
would be nice, the more automated, the better. It could very well be a
back-office process, giving as output a series of bugs that match
hardware (and then would be analysed by humans).

For *kernel* bugs, this would be simplified due to the automagic
collection of bug data (with same-named-attachments). But it is still a
bit complex since we do not have basic problem data as well-formed
attributes. This means, potentially, a hell of a problem on parsing --
say -- bug titles for clues.

Metadata, perhaps added to the description, might help; for example, a
series of key=value fields. But this would make, if the reporter is
expected to fill them in, bug reporting by casual users even more
complex.

(Which, of course, goes nicely with my previous comment that bugs are
*technical* thingies.)

One of the problems with "no mixing of affected users" on kernel (and
other hardware-related) bugs is that the sheer amount of unique bugs
cause many of them to die of old age. Recently, I myself received a
series of emails asking for more data/try new kernel/update BIOS, for
systems I do not have access to anymore, and for UBuntu versions
already obsoleted. These were interesting bugs when they were opened,
but now are on the track to be closed invalid.

In other words: I fully agree with Dave; at the same time I do
understand the kernel's requirement for one bug per user. Dave's
approach might help, at least a bit, minimise age/relevance issues.

Let's keep on, I like the suggestions :-)

..C..


-- 
ab alio expectes alteri quod feceris