[fab] Non-standard kernels in the Fedora Multiverse

[Greg DeKoenigsberg]

On Wed, 10 May 2006, Christopher Blizzard wrote:

> 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.

More thoughts about this:

What *is* Bugzilla?  

First of all, it's a database.  It functions reasonably well as a 
database, too.  We track thousands of components, and all things 
considered, it could be a hell of a lot worse.

It's also a UI in front of a database.  In this respect, it's pretty
limited -- largely because we treat it as monolithic web UI, and
monolithic web UIs always, always suck in some fundamental way --
especially as complexity grows.  I can certainly attest to this from my
days in RHN.

It's also a set of xmlrpc APIs.  We don't use this functionality nearly as
well as we could -- but in my opinion, exploiting these APIs is the 
future.  Ultimately, we'll need lots of different UIs for lots of 
different uses, and good APIs are the key to building these.

--g

-------------------------------------------------------------
Greg DeKoenigsberg || Fedora Project || fedoraproject.org
Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors
-------------------------------------------------------------