Repost of new bugzilla tool idea

Michael Schwendt mschwendt.tmp0701.nospam at arcor.de
Sun Mar 9 10:59:28 UTC 2008


On Sat, 8 Mar 2008 19:24:09 -0800 (PST), Arne Chr. Jorgensen wrote:

> hi,
> 
> It has taken me 1 day to file 5-6 minor bugzilla entries today. It such a pain that people avoid doing it, at least I have 
>

Yes, remote access to bugzilla.redhat.com is not anymore as good as it
used to be some years ago. The increasing size of the form data makes the
system slower and less convenient to navigate.

For querying bugs in specific packages, I prefer
  http://bugz.fedoraproject.org/PKGNAME
which redirects to the package database pages.

To file bugs, I use the XMLRPC Python interface to bugzilla. Once I have a
direct link to a ticket, I can open it with a browser if I need to, but
that could be much faster, too.

> A tool, with a simple email window type, where I may include info as you
> do to bugzilla is at hand. Communicate directly on a a separate port back to
> site.

What bugzilla would benefit from is an email-to-ticket gateway, so that
you can add comments to tickets via mail (as a reply to the mail you
receive). Because for a good percentage of the problem reports, two-way
communication *is* important. But quite many reporters give the impression
that they dump a report into the system and then hide somewhere. Perhaps
they ignore the bugzilla mails they receive (due to lack of time or
insight) or maybe they find the system and notifications intimidating?

> 2. At the other end, Bugzilla - the report will be filed under the Key ID, and so forth.
>

The key id refers to the GPG key that was used to sign the package. It is
used to sign other packages, too. It cannot be used as a package
identifier. What you have in mind is an ordinary mapping of RPM package
header details to bugzilla "Product", "Component", and (dist) "Version"
fields.

> So what is needed ?

More man-power to handle the increasing number of problem reports and
also fix the bugs.

> My reason for this suggestion, is that bugs exist for years without
> being fixed. And a lot of the reason is that bugzilla is a real pain,
> with little benefit for the user. It too ineffective. 

Too many bugs (especially minor/subtle ones), too many inaccurate problem
descriptions (e.g. missing steps on how to reproduce something), too many
problem descriptions where reporters flood a ticket with lots of comments
(it increases the time to process the input too much), unresponsive bug
reporters on the other hand, packagers which set NEEDINFO status in cases
where they ought to be able to understand/fix a problem themselves, too
few people capable of fixing bugs at the distribution-level instead of
upstream (also due to lack of the h/w needed to reproduce something).

An additional problem created by Fedora is the high number of updates,
which make the distribution a moving target. Nowadays, breakage is
relocated from the development branch into the stable dist releases.
Almost every version upgrade of a pkg introduces new bugs or reintroduces
older bugs. Dealing with the PRs occupies package developer resources
(even if they only forward them to upstream).

While I agree that bugzilla suffers from the size of the data and from the
number of tickets, I think you have false expectations. Those tickets in
bugzilla, that are not closed for years, are there because there is no
end of tickets, which are handled with a higher priority.




More information about the fedora-test-list mailing list