Mailinglist Archive: opensuse-project (370 mails)

< Previous Next >
[opensuse-project] Re: Improving the bug management lifecycle/process
  • From: Helen South <helen.south@xxxxxxxxxxxx>
  • Date: Thu, 17 May 2012 09:02:44 +1000
  • Message-id: <>
Forwarding the message I'd accidentally sent off-list. Hopefully it will
stay embedded in the correct thread.

In the light of what Jim says here - and others have said about the process,
too - perhaps it could be worthwhile to look at integrating FATE and
Bugzilla, but only if it doesn't come at the cost of becoming too complex to

The issue with the vast number of products making Bugzilla almost
unmanageable is an interesting  - and worrying - point, and even from the
user experience of having to navigate the selection options on the front
page, it's daunting.  Would it be possible to have a discrete instance of
Bugzilla purely for openSUSE/SUSE maintained separately to all the other

How did the system cope when we had Bug Squashing Days?



---------- Forwarded message ----------
From: Jim Henderson <hendersj@xxxxxxxxx>
Date: Thu, May 17, 2012 at 1:56 AM
Subject: Re: [opensuse-project] Re: Improving the bug management
To: helen.south@xxxxxxxxxxxx

Not sure if you meant to send this off-list - these are good questions
and probably should be in the ongoing thread. :)

On Tue, May 15, 2012 at 11:27 PM, Helen South <helen.south@xxxxxxxxxxxx>
It may be more prudent to first talk about the tool itself.  There's
been talk from time to time by people wanting to see FATE and Bugzilla
functionality merged because its too confusing going to two different
places and not clear to some people the distinction between the two

Hmm. I think they seem very different  - one is ideas and the overall
vision, the other with fixing breakages, really. Maybe it's a simple
matter of putting some messaging on the  gateway pages to help people
identify which they want.

They can be pretty different, but I've seen implementations of
Bugzilla that use it for both bugs and enhancements - and there is
some benefit to doing that.  For example, if someone submits something
they think is a bug but is in fact a request for new functionality
(which I see happen a bit in general - they think a program should
have some functionality and that it doesn't is a 'bug' in their mind,
even though it's new functionality), it's easy enough to recategorize
it in Bugzilla.  I think two systems puts us in the position of
telling someone who's misclassified a feature request as a bug that
they need to take it to another system, and we should try to reduce
having to redirect people to a different system.

Something that's integrated is going to be a bit clearer in terms of
managing expectations.  At the same time, Bugzilla isn't really geared
towards tracking enhancements specifically, and there are some
shortcomings in that area.  The question in that regard is whether or
not those shortcomings are show stoppers, or if even with them it
would be "good enough".

I think it's a good idea to keep it very focused at this point: fixing
the Bugzilla workflow. Much more likely to create results, rather than

Yes, I agree. :)

The numbers seem very manageable to me - a hundred, even a few hundred
- that's human-auditable. I'd been thinking along the lines of
scanning submissions for keywords, but for this kind of volume human
eyeballs are probably better.

Yes, I think so as well.  There is a tendency, especially amongst
non-technical reporters, to misclassify bugs (due to the nature of
them not knowing exactly how best to classify a bug).

Just having an initial browse of Bugzilla: not the most inviting of
search interfaces! Fortunately the Bugzilla conveniently
links to the submission-step-1 page with the 'hot 100' and 'two weeks'
search options. A lot of contemporary computer users won't do an
exploratory click to find out what they can find out: they have to be
told stuff (in bold letters) and guided through by the hand. Is
redesigning the user interface an option?

Probably not on, but maybe there's something we
can do to "front end" it.  Someone would have to do some research to
see if that's possible.  It might be possible to add a simple query
form, but even then for the non-technical, if they're not sure how to
classify a bug properly, they may not know how to identify a bug
that's similar enough to theirs.  Ultimately, the goal here would be
to reduce the work for de-duping bugs rather than to eliminate the
need to do that completely (that would be an unattainable goal, I

In the first instance I'm noticing some time being spent in marking
duplicates, I suspect language might be an issue for some - a non
technical user might not recognize a bug filed by someone who is
expressing it in more specific terms - eg 'my printer won't work'
versus 'cups-driver....'

Yep.  (See above).

Also noting some problems in trying to replicate an issue. I'm
wondering, with tricky issues, if there's some way to use
virtualization and information from the user's installation to
facilitate replication. How often is replication a problem? Is it
always necessary?

Intermittent issues can be much more difficult to dupe (that's been
part of the issue with solving the forums' issues the past several
months).  Duplication helps in diagnosis and /can/ shift information
gathering to the person fixing the bug rather than having to go back
to the original reporter(s) and having them try things.  It depends on
a lot on the complexity of the bug, though - something like a
difference between signed and unsigned might be relatively easy to
track down.  A kernel bug that manifests itself with specific hardware
(esp. hardware the dev doesn't have access to) becomes much more
involved and complex.

What have the people who are hands-on fixing these bugs stated about
the process? What really drives them nuts? What I'm seeing from my POV
might be very different to their experience.

These are good questions and we definitely will need to ask the devs
what their pain points are in order to try to resolve (or reduce)

Regarding the earlier observation about Novell's bugzilla being
stretched thin:  would you care to elaborate?

So I spent 8 years working for Novell in the training department, and
a couple of the things I was involved in were initiatives to track
issues with training courseware and the performance-based testing (the
hands-on exams for CLP/CLE), so I spent some time working with the
people who managed bugzilla.  I also have years of experience in the
Novell forums and have had access to large pieces of internal bug
tracking as a consequence of that.

The bugzilla permissions system (for example) is relatively
simplistic, so adding a new group to grant permissions to non-public
bugs is a pretty massive undertaking because Bugzilla was created
really to have things open rather than hidden.

As I recall, the number of products and components listed is testing
the limits of what Bugzilla can handle.  I've seen times with the full
product list where you select a product and the list of components
(which builds dynamically) seems to take ages to populate because of
the amount of data involved.  I think they've migrated to beefier
hardware, but the limits are still really being tested, and to my
knowledge, no other organization has an implementation of Bugzilla on
this scale in terms of product/component count.

I remember talking with the guy who used to run it (I don't think he's
there any more) and even trying to get minor customizations in order
to meet my needs (for example, being able to automatically create some
components for a consistently-created type of product - training
material - so we wouldn't have to manually create components for the
course guide, labs, and workbook) was something they didn't have the
bandwidth for.

As far as I know, the number of people to work on those types of
requests has been reduced rather than increased, so any customization
we'd want would be, I think, unlikely (but I'd be happy to be proven


IRC: helen_au

IRC: helen_au
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx

< Previous Next >