cross-site bug tracking

Christopher Blizzard blizzard at redhat.com
Wed Apr 11 14:12:34 UTC 2007


On Tue, 2007-04-10 at 17:20 -0400, Luis Villa wrote:
> About step (5). Does Fedora also automatically mark it fixed? Do they
> wait until the fix hits a tarball? (How do they know when it hits a
> tarball?) Does RHEL mark it fixed? What about other derivatives? What
> happens if the problem originated in RHEL instead of Fedora? These
> questions are difficult to answer, and the least-bad answers are very
> labor intensive.
> 
> I'm not a big fan of Launchpad (proprietary[1] and the UI is
> terrible), but I think aseigo is probably right- this doesn't get
> solved in anything more than a very, very labor-intensive way until
> there is a distributed bug system which is tightly tied to a
> distributed revision control system- conceptually, some combination of
> launchpad and rpath. Until then, the payoff for working hard on this
> is (IMHO) likely to be very low for Fedora, because no one will do the
> extra labor necessary to make it useful.
> 
> It won't harm anyone to have a more up-to-date bugzilla with openid
> and good inter-bugzilla transport mechanisms, but my sense is that no
> one should hold their breaths expecting it to solve substantial
> problems for Fedora.
> 
> Luis
> 
> [1] Don't get me started on how angry Shuttleworth's hypocrisy makes me...

A little pontificating, sorry:  Over time I've become less and less of a
fan of bugzilla.  Mostly because people see it as a hammer for all their
nails: bug fixing, task assignment, customer defect resolution and even
release management.  I think that other than "here's the issues that as
a developer I know I need to fix" it does a crappy job.

So for me, it's a question of leadership in this area to lead everyone
to something that just plain works better.  In my head I see a
collection of tools.  If you're a release manager, you can see what the
state of a release is.  If a program crashes it goes into a repo for
program crashes which can be mined for data (see mozilla topcrashes.)
Some of this is "better views of data" - i.e. different views of
bugzilla data - but I really believe that adding workflow that isn't
just flags on bugs is a great first step.

Bugzilla has been around a long time, and it's served itself pretty
well.  But I think that you've hit it right on the head there.  That
connecting defects to source control and letting fixes flow between
projects is important.  But no one has taken that first step to say
"we're going to go out and try to make this happen."

Should it be us?  Does Red Hat want to fund it?  (Based on the history
of ownership of both our internal and external tools, the answer is
probably no.)  Can we organize a community around solving that problem?
It's hard, since everyone has their own vision of what it should be, and
very often it's "bugzilla, with even more stuff on top!"  And things
don't really move.  It's hard to know what the next step is.  But I
would love to hear more ideas.

--Chris




More information about the advisory-board mailing list