Re: .desktop -> bugzilla

[hobbit aloss ukuu org uk]

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
  next point.

* You've seen how in the bugs-per-package listing you can get
  linked bugs?

  #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
  of others.)

* 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
  then).

* "reported by: root localhost" 
  "reported by:" 
  "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
didn't help.)

So.

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
everyone involved. 

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
> all.
> 
> 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
official one.

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.

Telsa