Re: .desktop -> bugzilla
- From: hobbit aloss ukuu org uk
- To: GNOME Desktop List <desktop-devel-list gnome org>
- Subject: Re: .desktop -> bugzilla
- Date: Thu, 15 Aug 2002 12:35:12 +0100
On Thu, Aug 15, 2002 at 06:27:27AM +0200 or thereabouts, Ali Akcaagac wrote:
> On Thu, 2002-08-15 at 05:58, Luis Villa wrote:
> > > KDE doesn't use bugzilla? It'd be nice if when KDE apps crash we can
> > > report bugs on them, and vice versa....
> > They still use debbugs, which is the ultimate proof that it is our
> > destiny to rule the desktop :)
> so ?
> i think their bugreporting system is far better than bugzilla.
I don't know whether you were around in the run-up to the switch,
Ali, or were privy to the situation we found ourselves in around
autumn of 2000. Here's the story on why Gnome uses bugzilla.
Pre-Gnome 1.0 I'm not sure. I rather think Gnome may have used
GNATS at some stage. But in 1.0 (1999), it was certainly using
debbugs. And by a year later, it was unmanageable. Gnome tried
to make it easy to submit bugs. I still think this was the
right thing to do. But it resulted in:
* Every time the user put the wrong product, it was filed there,
even if it meant creating a new one. There were separate products
for Abi, abi, abiword and abiworld (I think: some typo like that)
and this continued for every single Gnome product, for a bunch of
KDE products ("well, it was running in Gnome, wasn't it?") and
for Netscape, a JVM and some other non-Gnome app which apparently
everyone used (and broke) because we had dozens of reports on it.
Every time you moved them to the right category, someone reopened
the entire category by sending in a new report.
* Unlike Debian and KDE, which have things like 1 to 20 bugs
(okay, I see 97 for kdestop), we got ourselves into the situation
where we had over 1000 bugs in one or two categories, particularly
where apps were now unmaintained. This is _not_ a good situation
because it takes effort to sort out duplicates... well, see
* You've seen how in the bugs-per-package listing you can get
#xxxx: summary here
Package: packagename Reported by: emailaddress
merged with #yyyy Age: days. NN days old?
And then bug #yyyy has "merged with #xxxx" in its information too?
Well, if you get 200 bug reports which are all duplicates, imagine
how you duplicate them sensibly. You'd have "merged with #001, #002,
#003.." for _every one_ of 200 reports, and you'd immediately make
that list unusable.
The alternative is to leave them as duplicates, making the other
200 individual reports impossible to spot.
Yes, debbugs was probably not designed to be left until full of
such reports, but it happened.
* The size and speed was like an avalancke. Whilst I was sorting
one category with a very-easy-to-trigger bug which generated
hundreds of identical bug reports, I reached a stage where
I got the total down to something like 400, cheered, and then
the next _day_ it was back up to over 500. I was doing this
nearly full-time and drowning. (And it wasn't just me: there
was Malcolm Tredinnick, there was Kjarten Maraas, there was
Morten Welinder and his magic scripts which were closing hundreds
of information-less bug reports per _day_, and there were plenty
* Querying was... less than stellar. I think this may have improved.
But there was no way to query to see if your bug has been reported
short of starting a browser or sending off the right incantation to
control And then getting a huge list of subject lines, typically
[Crash at IP.address.goes.here]. People just won't do this. They
send off a new report instead (see prior point for what happens
* "reported by: root localhost"
"reported by: root 127 0 0 1"
However potentially useful these reports were, if we could get
just that one bit of information extra, we couldn't get it.
Occasionally they were helpful. Alan once claimed that it was
a six-word bug-report from such a user that helped him find
one bug, but that was one report. We had dozens flooding in
daily from this "address".
* Developers couldn't categorise into "stuff to do now, stuff to
do later" and so on. They couldn't even find the valid reports.
And if you think bug reports lack information currently, you
should have seen the ones Morten's scripts were closing. One
of them simply checked for "is there content in this report or
is it empty?", I think.
* Far too easy to abuse. There was some real filth directed at
Gnome and people in it just because it was so easy to send stuff
without having to provide an email address. It is not fun to
read this stuff. There were also accidental closures of the wrong
bug via email.
* Once a report's been closed, it vanishes. It's hard to keep a
list of "I'm sure I've seen that before" then.
* Attachments. Oh ye gods, attachments.
* (This may still be a problem now). There was a situation where
if you closed a bug report with a message to the original reporter,
the original reporter didn't see the message. You had to put them
into a Bcc line or something (I forget the details). Consequently,
when I closed some hundreds of duplicates of gnorpm with a message
explaining where to get the fixed one and how to use the command-line
version of rpm to install gnorpm (because most reporters couldn't
use rpm: there was a reason they were using the GUI version...), I
had to write a script to mass-mail all the reporters separately.
(And I ran out of file descriptors or handlers or whatever they
are when I ran it.) Had I closed all those reports with the message,
_they would none of them_ received the "how to get the working version
of this app you can't do without" explanation. That's an extreme
example, but it was happening all the time that we closed bugs with
a message and the reporter never saw it. I had a bug closed in
the Debian tracker with a message, and never saw the close message
until I went back and hunted six months later, so I think this is
still an issue. So people didn't know there was a fix, and so
they kept using the old buggy version and finding and reporting
more bugs which had also been fixed.
* And so on. You can see a snowball effect here, I imagine. All of
these fed off each other, and that was the situation that had
come about in a year.
So. That's what happens when it's easy to report the bugs. Then
what do you do with them?
Your list of bugzilla issues:
>- their users don't need to deal with an horrible interface.
> - you can report bugs right from the app.
> - no crappy login which requires another password.
> - it does what it has to do. simply reporting bugs.
...is by no means complete. Believe me, there were many other
issues that worried us about Bugzilla, but it was abundantly
obvious that we had to do something. Developers weren't touching
debbugs because it was impossible to query, impossible to prioritise
in ways we needed, and just too horrible because it had got
into that state. Bug-buddy was in its early stages and people
were using it on stripped binaries so half the reports were
# 5 ?? in ()
# 4 ?? in ()
(and these had passed safely through the scripts that looked
for things like "completely empty reports with no package name"
and closed them)
And we eventually had so many bugs there that the six-hourly
"redo the database" cron job was not completing before it was
time to start again. (Okay, it was a small slow box, but this
Read these threads in the archives and you'll see that I was one
of the loudest "bugzilla worries me because..." yellers. (And
please read at least the first, because it took me half an hour
to dig them out of my old mail.)
gnome-devel-list: Aug 2000: Does the bug tracker actually work?
gnome-hackers: Oct 2000: Bugzilla for GNOME
gnome-hackers: Oct 2000: Bugzilla for GNOME is ready for Beta test
gnome-hackers: Nov 2000: Bugzilla outstanding issues
(then posts through early 2001: I got bored of hunting these.)
In particular we were worried about:
* slow links and the size of the pages
* how to report bugs if you had intermittent-only net access
* small boxes and netscape/mozilla requirements: there was
only lynx as a text-browser them and it wasn't happy with
bugzilla at all
* whether to require email address (and privacy issues)
* would developers use the damn thing after we moved?
* complexity of the bugzilla interface.
Martin Baulig put the email interface in largely because I whinged.
It made it hard to upgrade bugzilla because of the changes, and I
don't think that many people use it even now. (Does anyone?) But
he bent over backwards to tweak it according to the wishes of nearly
Jacob rewrote bug-buddy almost completely to deal with bugzilla.
It had been written with debbugs in mind. That also required a
hack to bugzilla.
> it may for sure have issues that i haven't seen yet but from an users
> point of view it can't go easier. how many bugs did you people missed
> for gnome because the user doesn't want to create yet another account
> for reporting some stuff. even bug-buddy isn't that comfortable after
> after all this may be for sure a matter of taste too.
Partly. Partly it's a matter simply of "what works". debbugs was,
ultimately, _not_ working for us. We really have got a lot more done
more rapidly with bugzilla, and I think far more developers are
using bugzilla than were actually looking at debbugs. Far more
non-maintainers looking for something to fix are doing it too,
and this is really making a difference.
Finally it was all made moot. Martin Baulig had set up a test bugzilla
and imported all the debbugs database into it. We were testing it
at bugzilla.gnome.org whilst bug-buddy continued to throw things
at bugs.gnome.org. And then... bugs.gnome.org suffered hardware
failure. We had hammered on bugzilla for about a month, I think,
and even I was coming to the conclusion it was a better option.
But after the debbugs box died, there was really no choice. We
could either throw out _all_ the bugs (and history) by restarting
with a system we knew most hackers wouldn't use; or we could use
bugzilla, which had all our bugs in already. There was actually
support for the idea of binning all the old reports in some
quarters, and making a fresh start. It would have been far far
easier. I thought, and still think, it would not have been the
right answer. Luckily, I wasn't the only one to think that way.
We elected to keep working and turn the test bugzilla into the
So someone made sure there was at least an MX record for the old
bugs.gnome.org so that bug-buddy kept working, and off we went.
The people on gnome-bugsquad and #bugs started hammering, and
we tried to categorise everything, and we added keywords and
Luis arrived (and, although he hasn't come into this story so
far, I have to say that this was one of the really important
bits, because Luis understood all about taming large bugzillas
which were receiving hundreds of reports a day), and we found
reports that had lain stagnant for a year, and we found patches
and applied them, and well: it may look complicated now, but
the alternative is all those bugs in a heap. We received them
all. We can't bin them without at least looking at them.
So. I hope that explains why Gnome uses bugzilla. Honestly, Ali,
if there are better apps which work better for users, developers,
bandwidth, and so on and have a free licence, I'd love to hear
about them. sourceforge won't do. We get people with sourceforge
projects wanting space in our bugzilla, in fact. I'm not even sure
rt was about then, but it certainly wouldn't have done. jitterbug
is a patch repository more than anything. We tried gnats (I think,
way back in the mists of time when there was "the gnome tarball"?)
We tried debbugs. bugzilla _is_ better for our purposes.
Yes, we could improve it. There is a team of about 12 people
(I suspect) who read bugmaster mail, and believe you me, the
complaints and rudeness we get there from people who don't
like the bug-tracker is an education.
But please don't assume we switched to bugzilla and thought
"damn what the bug-reporters think". We didn't do that at all.
] [Thread Prev