[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [fab] Non-standard kernels in the Fedora Multiverse



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]