Category Archives: QA stuff

Continuing the 2nd Debian 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. 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 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,, 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 Help reviewing them will be appreciated.

Leave a comment

Filed under Debian GNU/Linux, Mozilla, QA stuff

Status of the binNMU unsafe packages

Back in July, I started reporting bugs against binNMU unsafe packages. All reports include a patch, to ease the work of the maintainer.

During the last 8 months 58 bugs were closed and 19 more and still open. Resulting in an almost empty page for Lintian’s not-binnmuable-any-depends-any tag. The not-binnmuable-any-depends-all and not-binnmuable-all-depends-any aren’t that fare behind.

We still have 572 packages which use the old style substvar (“${Source-Version}”). As this is used with arch-dep only packages, they are still binNMU safe, as all the packages get the version number increased, so nothing breaks. See Lintain’s substvar-source-version-is-deprecated tag for more info.

The numbers above might change a bit due to extending the binNMU checks, but I don’t expect them to change too much.

Leave a comment

Filed under Debian GNU/Linux, QA stuff

Status of the 2nd Debian 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 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 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,, QA stuff

The 2nd Debian bug triage

In 24 hours 21% of the triage is already done due to an amazing responsiveness from Debian’s 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 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, 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,, QA stuff 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 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 without running unstable…

So, I’m glad to announce the beginning of (my) 2nd bug triage. This triage targets 285 bugs out of 330 open 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 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,, 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 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,, QA stuff