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.

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.

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…

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.

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.

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.

Triaging bugs – continued

While the Firefox/Iceweasel triage is in progress, and it is going quite well with about 1/3 of the bugs already being handled (most of them still exist), I started a triage for the cvs package.

As cvs has “only” 145 bugs, I could apply some of the suggestions people offered (mostly by complaining on -devel) . I started with doing a quick maintenance for the bugs, verifying some easy ones, merging similar reports and even found one already fixed. Another side of this was to add the missing version info for some bugs.

Note for DDs: Don’t forget to add version info when reassigning a bug.

The bugs were chosen based on version info, and everything reported to a version older than 1:1.12.13-1 will be pinged. I must admit I wasn’t sure about how to approach a few 1 to 9 years old bugs, mostly feeling ashamed we (as a project) still haven’t fixed/answered them by now.

The next target for triage is aptitude, which should be a more difficult triage as it has 450 open bugs. I don’t know when I’ll start it, probably depends on how well will the ongoing triages will end.

Firefox bug triage

Today, I started doing the Firefox bug triage. A request to reproduce or close bugs was sent to 324 bugs’ owners. Most of the bugs were reported against Firefox version 1.5 (or lower).

As some people responded quite quickly, about 10 bugs were closed and another 10 were reproduced (or confirmed to still be relevant). The latter got reassigned to Iceweasel for further handling by the maintainer.

I hope people will continue to be responsive…

If someone wishes to follow this triage, simply look at the Firefox bugs list.

Bug triaging on various packages

In the end of the my last post, I’ve offered to package maintainers who need help with bug triaging to contact me. While no mails arrived, I decided to take a more active approach.

Baruch Even referred me to “Status of Maintainer’s packages, ports and bugs“, from which I could find quite easily the maintainers who have a lot of bugs. After a few manual processing and checks, an offer of help mail was sent to the maintainers of openssh, cvs, grub, cupsys, apt, dpkg, bind9, postfix, util-linux, file, xmms, wine, xorg, xorg-server, xterm, iceweasel, aptitude and emacs21.

Although only a few answered the mail, I think I got enough “work” to do. I’ve agreed about the goals for a bug triage for aptitude and ice{weasl,dove,ape} with their maintainers.

I’m pleased with the openoffice.org triage method I used, although I got some comments and suggestions from people which I’d like to apply. I’ll try to use some of Ana Guerrero’s scripts for this end.

Wish my luck (:

openoffice.org bug triage – the end

During the last 6 weeks I’ve been working on the debian openoffice.org bug triage, targeting 166 old bugs reported against versions lower than 2.0.0.

Today, I’ve closed all the remaining bugs without response from the submitter to the 3 pings sent.

During the process, 50% of the bugs were found to still be relevant for recent versions of openoffice.org or to be already fixed by them.

For those interested, the final statistics are:

24 bug reproduced.
61 bugs closed as fixed / not relevant any more
81 bugs closed due to lack of submitter response.

So the oo.org bug count decreased from around 500 to around 350. So I hope this will help to openoffice.org team to focus on the remaining bugs.

As 350 bug is still a lot, I intend to repeat the process when version 2.2.1 will enter testing.

p.s

If any other teams think they need help with bug triage – you’re welcome to contact me.