Firefox triage has ended – 300+ bugs processed

It took half a year (including a long pause), and the Firefox triage is finally over. The last part, reviewing 120 bug reports took about a month. Starting with 324 bugs, the triage ended with 10 open bugs which I left for the maintainer to handle himself.

Although I didn’t keep record about the exact numbers about how many bugs were found to be fixed, it seems that ~250 bugs were closed (fixed, not relevant any more, whatever…). This leaves ~70 bugs to be valid (all reassigned to Iceweasel and got the right version info).

As I see it, the biggest problem of the large package maintainers have is to figure out if the bug is Debian specific or upstream only. The latter should be reported upstream by the users (when possible) to lower the pressure on the maintainers.

I my recent triages I saw a lot of upstream only bugs reported only in Debian, since the maintainers can’t be just “bugs forwarders”. It might work well in small packages, but this doesn’t scale up. So when possible, please try and report bugs upstream…

Anyway, I’ll probably initiate another triage for Iceweasel when version 3.0 will enter testing (probably post Lenny).

About these ads

8 Comments

Filed under Debian GNU/Linux, Mozilla, QA stuff

8 responses to “Firefox triage has ended – 300+ bugs processed

  1. Zack

    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.

  2. Lior Kaplan

    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.

  3. 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.

  4. Sven Joachim

    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.

  5. Sven Hoexter

    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.

  6. 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

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s