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…

3 Comments

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

8 Comments

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.

4 Comments

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.

3 Comments

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.

p.s.

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…

5 Comments

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