[fab] Non-standard kernels in the Fedora Multiverse

[Christopher Blizzard]

Greg DeKoenigsberg wrote:
>>> And starting to get bug reports from J. Foo's Fedora
>>> that has a drastically different kernel or glibc or ... is going to make
>>> things very very difficult for developers.
>> Not for you, for whoever is maintaining the Alternatives pkg.
> 
> I think Jeremy's fear about misattribution of bugs is a valid one.
> 
> I have a dream, though.
> 
> I have a dream of a desktop bugzilla client in Fedora.  When you find a 
> bug, you fire up the prominently-placed client.  The client presents you 
> with package names, and you select which package the bug was in.  The 
> client will be smart enough to reconcile any questions about "which repo 
> this package came from".
> 
> Is this a crazy dream?  Maybe.  Maybe not.  But it'd certainly require a 
> visionary QA person to make it happen.  Right, Will?

Yes!  This is a great start.  Here's some more thoughts on this.

1. The fact that a bug can only be in one component pretty much sucks. 
We're stuck with this data model that bugzilla presents, everyone gloms 
on top of it and we're stuck with some very bizarre interactions.

2. I assert that Bugzilla is a pretty bad tool for release management, 
because once again it only deals with a component at a time along with a 
large number of other things.  As a side note the release meetings at 
Red Hat are pretty funny, walking through bug numbers, trying to figure 
out information.  Everyone needs to be their own expert in particular 
package and has to bring it to the table instead of being able to 
maintain release-specific summaries somewhere.  Internal/external or 
fedora/RHEL, it doesn't matter.  They both have the same problems and 
bugzilla is part of the problem.

3. Collecting information about crashes should probably be a completely 
separate activity than bugs.  Bugs are about identified problems, and 
crashes have a many-to-one relationship with bugs.  Some experience from 
the Mozilla project is relevant here.  We get a huge number of crash 
reports from users on all our major platforms.  We treat those crash 
reports as data and have tools to mine stack traces, find top crashes, 
etc.  Then we turn that data into a bug that needs to be fixed.  It also 
allows us to target the highest-visibility problems in the product, or 
the one that affects the most people.  Basically "something just 
crashed" and "this doesn't work like I expected" are very different 
problem reports, and should be handled differently.

So that's my little rant about Bugzilla.  As for reporting, I think that 
we can do a lot better than what we have now.  Which is, uhh, nothing 
really.  Bug-buddy kind of works, but not well.  I think greg is on the 
right path, but we need some real thinking about who we're targeting. 
People like us?  Our users?  Unsophisticated people?  Basically I think 
that before we dive in we want to do a really good job of defining the 
problem, otherwise everyone will have different ideas about what we're 
building to enable better crash and bug reporting.

--Chris