Tag Archives: bug triage

The 2nd Debian Openoffice.org bug triage has ended – 300+ bugs processed

The 2nd bug triage began with 285 bugs, which grow to around 310 bugs, since during the 4 months of the triage more bugs were reported.

So, I’m glad to announce the beginning of (my) 2nd openoffice.org bug triage. This triage targets 285 bugs out of 330 open oo.org bugs. The selected bug are ones which were reported against versions lower the 2.3.1 or have no version information at all.

At first, the triage advanced quickly with 21% of the bugs processed during the first 24 hours and 40% during the first 10 days. This left a long trail of bugs to handle manually.

The triage began for version 2.3.1, but was delayed to let version 2.4.0 to propagate into Lenny, as that was Rene’s preferable version to release with. When the triage resumed in late April, I had a 2.4.0 available in all of our repositories (sid, testing and backprots). Which meant that everyone could verify their bugs against the same oo.org version. Bug triaging heaven (:

Two thirds (66%) of the bugs were closed in this triage, most of them after a check from the submitter or myself and a few after the submitter was unresponsive and I couldn’t verify the bug myself.

Verifying the bugs myself is the most demanding part of the triage. Reading each report and understanding the problem takes a lot of time. Reproducing the problem usually takes less time than understand it. That’s way have test cases attached to bug reports are so important.

In several cases the instructions were so simple I could just open the file, check something and verify the bug. That was done in a robotic manner or in a monkey like one. These kind of attachments enables a lot of people to help with triaging, even if the lake the technical background of the program in subject.

So after closing 200 bugs and verifying around 100+, the oo.org bug count is set to 140 outstanding bugs, and 70 bug being forwarded to upstream. Except from about 10 bugs, all of the remaining 130 bugs are relevant for version 2.4.0. No need to wonder if the bug still occurs before reading the report…


Filed under Debian GNU/Linux, Openoffice.org, QA stuff

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


Filed under Debian GNU/Linux, Mozilla, QA stuff

Continuing the 2nd Debian Openoffice.org bug triage

Short version: 155 bugs processed, 130 bugs to go

Reminder: The target of this triage is to clean all bugs not relevant for version 2.4.0 in Debian.

Openoffice.org 2.4.0 entered Lenny (testing) two weeks ago, and last week Rene created a backport for Etch (stable). This means our users can test 2.4.0 on whatever (recent) Debian version the use. So it seems like a good time to revive the 2nd Debian Openoffice.org bug triage.

The previous round ended with ~150 open bugs. After another manual scan of the bugs, the count is 130 open bugs. Seems that some people insist on replying my mails to the BTS alone and not CC me to their answers. Thank god for the “last modified X days ago” line in the BTS… otherwise I counldn’t have caught those so easily.

From the remaining 130 bugs, only 10 are marked against versions 2.3.x. Meaning we have much info to collect in this triage (or a lot of bugs to close if we fail to do so).

1 Comment

Filed under Debian GNU/Linux, Openoffice.org, QA stuff

Closing old Firefox bugs

Back in October I ran a Firefox/Iceweasel bug triage which resulted in handling 60% of the bugs. 5 months later, this leaves ~130 bugs which I’d like to close as the submitters aren’t responsive (2/3 pings as usual).

It will probably take me some time to manually review the reminding bugs before closing them. The reason for manually reviewing the bugs is to try and lower the false positives. Although I don’t see too much of them anyway as there were enough chances to verify them.

The list of the old bugs is at http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=firefox. Help reviewing them will be appreciated.

Leave a comment

Filed under Debian GNU/Linux, Mozilla, QA stuff

Status of the 2nd Debian Openoffice.org bug triage

10 days have passed since the start of the triage, and more than 40% of the bugs were handled. 71 bugs were confirmed to be already fixed in recent versions of openoffice.org and about 50 were confirmed to still exist.

During FOSDEM, I talked with Rene about the triage and it seems he intends version 2.4.0 for Lenny. So I decided not to ping users again until 2.4.0 (a non RC version) will enter Lenny, as don’t want to ping our Lenny users twice.

Dan Jacobson opened a thread about the new style of “mass triage” on -devel. Most of the points were already answered on my triage announcement post. But the thread on -devel have resulted in a few interesting points:

  • Some of our largest (as openoffice.org) and important (as aptitude) packages are under maintained – referring to the amount of people working on the packages relatively to the amount of work which needs to done.
  • While we have under maintained packages, people are still eager to add new packages instead of helping existing packages. Notice the amount of ITPs we have in the WNPP page.

On the users “frontend”, I found a lot of thankful people who gave possitive feedback on the process. Others were just responsive enough to get things forward and in some cases I could help with checking the bugs themselves instead of “just” pinging people about them.

Some users even took the opportunity, and upgraded to Lenny to test the bugs, and I still have a few bugs waiting for similar upgrades to be completed. It’s very nice to see users willing to invest time and effort to help DDs.


Filed under Debian GNU/Linux, Openoffice.org, QA stuff

The 2nd Debian Openoffice.org bug triage

In 24 hours 21% of the triage is already done due to an amazing responsiveness from Debian’s openoffice.org users.

From the total of 285 bugs targeted by the triage, 35 were closed and 27 were reproduced. Another 20 bugs are in my processing queue.

With today’s result the total bug count for openoffice.org in Debian crossed the 300 outstanding bugs mark. I hope to lower it to the area of 200 by the end of this triage.

I must say most users were very happy to see their bugs’ get some attention, and some were really happy to see their bug was already fixed. I got a few mails with very warm words about the triage, openoffice.org in debian and the project in general.

Getting this feedback from users is one of the things that motivates me to keep and contribute to Debian in general, and to do bug triages in particular.

One issue I noticed is that some of our users don’t know how to close bug reports. While it’s more important they’ll know how to report bugs than how to close them, it’s a good idea to refer them to “Closing bug reports” on Developers’ information regarding the bug processing system.


Filed under Debian GNU/Linux, Openoffice.org, QA stuff

Openoffice.org bug triage

Lior: “My name is Lior, and it has been 6 months since my last bug triage.”

Support group: “we love you Lior…”

While I was thinking of doing another openoffice.org bug triage for version 2.2.1, version 2.3.1 had already entered testing. Meaning the versions in testing/unstable are very similar. This also means users can easily test a fairly recent version of openoffice.org without running unstable…

So, I’m glad to announce the beginning of (my) 2nd openoffice.org bug triage. This triage targets 285 bugs out of 330 open oo.org bugs. The selected bug are ones which were reported against versions lower the 2.3.1 or have no version information at all.

The goal of the triage isn’t to close as much bugs as possible, but to get all the bugs updated with recent version. Hoping “not relevant any more” will be the answer for most pings. Last time about 1/3 of the bugs were reported as already fixed / not relevant any more.

For those of you who will get one of my pings, please don’t forget to send you current openoffice.org version info.

I know some of you don’t necessary agree with this method for closing bugs, as it allegedly puts the burden of testing and updating bug information on the users/reporter than upstream.

While I partially agree, I don’t see how can teams with so much bugs can handle all the bugs themselves without having someone doing a full time job on this issue (any volunteers ?).

People wish to review the progress of the triage (or even help…) can check the triage bugs list.


Seems I was too slow with this triage, version 2.4.0~rc1 is already in unstable…

p.s. 2

It’s been only 4 moths since my last triage…


Filed under Debian GNU/Linux, Openoffice.org, QA stuff

Thinking of another triage for openoffice bugs

With the release of version 2.3.1 and upload to unstable, I started to wonder if it’s time for another bug triage for openoffice.org package.

The last triage targeted bugs older than version 2.0.0, but now I’d like to target versions 2.0.0 to 2.2.1 (which is in testing right now). Preferably getting answers for 2.3.1 in unstable.

Another goal for the triage is to add up-to-date version info to the bug reports, as I think it makes the maintainers’ life a bit easier.

The actual question is whether to start now or to wait for version 2.3.1 to enter testing. The problem is that I don’t know when would this happen. It took a “while” for 2.2.1 to do so.

1 Comment

Filed under Debian GNU/Linux, Openoffice.org, QA stuff

Status of the Firefox bug triage (and what I learned from triaging bugs)

The Firefox bug triage started a month ago, with the goal of verifying the relevance of bugs reported against the firefox package, which isn’t present any more in unstable.

From the 324 bugs I started with, 37 have been closed and 85 were verified. The latter were reassigned to the Iceweasel package and got the necessary version info. 165 bugs are still pending for verification.

Additional 37 bugs are forwarded to the Mozilla bugzilla, most of them are open for a long time. Help with forwarding more upstream bug to the bugzilla is always welcome.

The status of the triage is available at the firefox bugs’ page.

During my recent bug triages (openoffice.org, cvs, firefox), I think we need to add a “be kind to QA people” section along with the “be kind to porters” one. I encountered a few people thought the goal of the triage was to bother them than to get bugs solved (or at least ease the maintainer to attend to them).

One even got an angry reply back after complaining too much about getting an extra mail:

I must say that I don’t understand your lake of patience. So you got another mail… we all get dozens of them everyday. I invest time in doing the ugly QA work, and I don’t I deserve this attitude.

But on the other hand, I had a few people thanking for the fact that someone invested time in their reports, and others that were patient regarding a few mistakes I made.

One conclusion I have from the triage process – our DDs don’t use versioning info enough. This makes going over reports harder and more time consuming. It also harder for the maintainer to figure out if the bug is still relevant for a new version.

1 Comment

Filed under Debian GNU/Linux, Mozilla, QA stuff

Status of the CVS bug triage

The CVS bug triage was started two and a half weeks ago. Considering the time frame, it’s going great.

I started with 145 open bugs, and 3 forwarded to upstream (which doesn’t keep track of old bugs, AFAIK). And now only 53 (about 1/3) of the bugs still wait for confirmation about their status. During the triage, 38 bugs were closed and around 50 bugs were verified to still be relevant.

All these numbers means that CVS has 57 bugs which are pending and verified to occur in the latest version. At least 10 of them can be solved quite easily as they have patch or an explanation good enough to be considered as a patch. The rest should probably require more work from the maintainers and upstream.

During the triage, a lot of work was invested in reproducing bugs when the submitters said they can’t do that themselves anymore (not using CVS or not using Debian). Another bunch of of bugs got better tags (mostly patch tag) and up-to-date version info to ease the maintainers’ future work on the package.

The bugs waiting for verification bugs were user tagged so they can be followed easily. Help with those is always welcome.

Leave a comment

Filed under Debian GNU/Linux, QA stuff