Michael Schwendt wrote:
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.
It never has been satisfactory, especially for dialup users. Many years
ago I suggested an email interface, nothing as complete as Arne has
proposed, and as I recall Mike Harris was going to write one.
Then he joined Red Hat.
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?
A tool that runs on my system is good. Especially if it works in text
mode. However, it cannot rely on being run on the problem machine - I
have a system right now that was unbootable for a time.
Debian has such a system, though it isn't at all compatible with
Bugzilla. However, since Debian has more packages than anyone else, and
supports (or did until recently) support more architectures than anyone
else, it's likely that Debian has a significant number of bugs.
However, I don't suppose Red Hat is ignorant of it. and it's fair to
note that Unbuntu has never used it; U used Bugzilla for a while, but
has switched to something else.
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.
Speaking of which, I'm a little puzzled at "priority." I'd have thought
that a breakage that has the potential to make a release (I'm thinking
of a kernel bug I reported recently and have mentioned here, and which
_might_ be a mkinitrd bug) would have a high priority.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
