Comments on: Firefox triage has ended - 300+ bugs processed

By: Více než 300 bugů týkajících se Firefoxu bylo vytříděno (Debian-linux.cz)

Více než 300 bugů týkajících se Firefoxu bylo vytříděno (Debian-linux.cz) — Mon, 05 May 2008 12:55:05 +0000

[...] bugů neprobíhá jen v OpenOffice.org, ale Lior Kaplan řeší také problémy ve Firefoxu. Celý proces začal přibližně před půl rokem s 324 nevyřešenými bugy. Řada z nich byla [...]

By: Gerfried Fuchs

Gerfried Fuchs — Fri, 02 May 2008 09:34:58 +0000

Telling users to report to upstream has several problems:

-) They have to be told where upstream wants their bugs, and in what way
-) That has to be done for every new user of the package, and for returning users because they have forgotten since the last time
-) Some users might stop reporting bugs because like zack said, they want (and rightfully) a single way to report bugs

If you think about it, investing time to educate users along that line will cost you way more time than forwarding the bugs yourself. The maintainer should have a working communication channel with upstream anyway and forwarding a bug isn’t much of a trouble, trying to educate users to use upstream bug tracking systems which are a lot different, one from the other, is just wasted time

By: Sven Hoexter

Sven Hoexter — Fri, 02 May 2008 08:20:47 +0000

Hi,
Zack I would really like to agree with you for the outlined reasons but after all it won’t scale.
When I took over LyX packaging with Per about two years ago we had a backlog of ~80 unhandled bugreports. It took us about 1,5 years to handle them all. I had to invest a lot of time to reproduce bugs that e.g. only happen if you use fvwm or with some rarely used latex class. And then we had bugreports that only happen with $special-kernel-version on $users-special-system and because everything else seems to work it could be your package.
As you can’t simply reject such bugs with “oh I’m not using this go away” you’ve to setup a testing enviroment and try it out.

On the other hand the result of forwarding such corner case bugs to upstream (after you finally can confirm them) is often that they rot in another bts because nobody from the upstream devs works in a similar enviroment and can’t reproduce them.

I guess that’s the ugly side of OSS development and what can happen if you can’t help yourself. But I still don’t think that it’s the best idea to load the burden on the shoulders of the package maintainers. IMO it would help to ask the ‘advanced users’ to fill bugs upstream if they’re sure that it’s not a Debian specific problem. Of course upstream would be soon annoyed if he had to deal with a growing chunk of bugreports that can be traced back to distribution specific patching.

Beside that I’m annoyed by the fact that people report bugs and then give a shit about what happens with them and don’t answer to requests to test something or clarify their reports. I’m investing my freetime to help to improve some software they reported a bug against and then they simply don’t care.
LyX is rather small and has a very nice user community with mostly helpfull and responsive users and developers but when I image how big the user base for e.g. firefox is and how many bugreports will be a dead end I can completly understand why a maintainer doesn’t really care to work on the bugs.

By: Sven Joachim

Sven Joachim — Fri, 02 May 2008 06:24:35 +0000

I don’t know if it’s even possible to report Iceweasel problems upstream (never tried, if you use neither Flash nor Java nor Javascript there are simply very few problems), but the big yellow box on http://www.mozilla.org/bugs/ suggests it might be dismissed without being looked at.

By: glandium

glandium — Fri, 02 May 2008 06:22:51 +0000

For bug count evolution: http://people.debian.org/~glandium/bts/i/iceweasel.png

By: Marc 'Zugschlus' Haber

Marc 'Zugschlus' Haber — Fri, 02 May 2008 06:17:01 +0000

I agree with Zack. Bug Triaging scales quite well. While this may be a challenge for big packages like KDE, OOo and Mozilla products, adding more people to the team can counter this scaling effect. I have not yet seen a request by the Iceweasel maintainers that they are in need of help for bug triaging.

By: Lior Kaplan

Lior Kaplan — Fri, 02 May 2008 04:59:53 +0000

You’re right, but the problem is that this method doesn’t scale up. So for large packages, the maintainers can get them self busy only with forwarding reports upstream.

I also saw people not reporting at the upstream BTS only because they are lazy, not because they don’t know how to.

By: Zack

Zack — Thu, 01 May 2008 23:56:23 +0000

I vehemently disagree. It should be the maintainers’ responsibility to forward upstream bugs upstream, no matter how big the package is, for three reasons: First, because the users shouldn’t have to understand more than one bug tracking system; they should be able to just use “reportbug”, no matter what the issue is. Second, users can’t be expected to figure out what is and is not an upstream bug. Third, my personal experience with upstream bug tracking systems is that about 50% of bugs reported there receive no response whatsoever; my experience with the Debian BTS has been much better. The Debian maintainers for a given package are more likely than the average user to know whether it’s even worth bothering to try to get the bug fixed upstream.