An invalidated bug. Should it have really been invalidated?

[Phil Wyett]

On Tue, 2013-08-13 at 19:34 -0500, C de-Avillez wrote:
> 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
> 

Looking at bugs and the reporting process. I am going to leave this for
a week and see what comes out of:

https://blueprints.launchpad.net/ubuntu/+spec/community-1308-quality-reporting-bugs

at next weeks vUDS.

Regards

Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20130820/6e60fcd0/attachment.pgp>