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
