Tag Archives: reportbug-ng

Reportbug-ng can now hide closed bugs

Today I finally found the reason why the table in reportbug-ng was not always sorted correctly. The fix was trivial and I’m happy it’s finally corrected. As announced last week, reportbug-ng now also can optionally hide closed bugs, which makes reportbug-ng together with the complex queries a great tool for finding easy NMU candidates.

To play around with those new features, I also did 5 lazy NMUs today. Most of them where fixes for FTBFS/RC bugs which had already a patch in the BTS.

Reportbug-ng now supports complex queries

Until today you could only use reportbug-ng to query the BTS with simple queries like “packagename”, “bugnumber”, “tag:patch”, etc. But the BTS actually supports composite queries like “severity:grave tag:patch” which returns bugreports with severity grave and a patch. The underlying Python library python-debianbts also supported this right from the start, but reportbug-ng did not make use of it.

Last weekend I finally had the time to fix that and the result is on it’s way to unstable.

Composite queries provide a very convenient way to find cheap NMU candidates: the query "severity:critical severity:grave severity:serious tag:patch" will return release critical bugs which have a patch. Now you can just go through this list, pick an open bug, test the patch and do what’s necessary to release Squeeze in time.

Next item on my list is an option to hide closed bugs, maybe next weekend.

reportbug-ng has localization support again

After having ported reportbug-ng from PyQt3 to PyQt4 over a year ago, reportbug-ng lost it’s localization, since the gettext based translations where incompatible with Qt4′s translation system.

This weekend I finally had the time to have a closer look at this problem. To make a long story short: I have ported the gettext based system to Qt4′s system. All the old .po files where converted to .ts files, but almost all strings are marked as “obsolete” so that they don’t appear in the translated program. But since they are still available in the .ts file, it is easy to get the translations up-to-date. So far only English and German are complete, but eventually other translations will be added.

PyQt4 makes it by the way really hard to get non-Qt strings translated.

Package Completion for Rng

Today, I finally found the time to apply a patch contributed by Daniel Schaal to reportbug-ng. Among two minor fixes it brings a huge usability improvement: package completion. Whenever you type something to the input field rng suggests package names matching that prefix:

That should make bug reporting against packages with cryptic names like libraries a lot easier. Thank you very much Daniel!

Using rng for bug triaging

Reportbug-NG’s ability to filter and sort bugreports in various ways can greatly help triaging bugreports after a certain criterion.

In this example I use the bugs of the KDE team, because they have quite a lot of bugs and are currently on a bug triage.

Two releases ago I tried to help them cleaning their BTS from obsolete bugeports. My tactic back then was to find bugreports where no action has been taken for a long time. I noticed that there was no easy way to find such bugs since neither reportbug nor the BTS allowed to sort the bugs this way, so finding the candidates I searched for was very cumbersome.

So let’s try to find those bugs with rng: To get all bugs belonging to the KDE team start rng with the maintainer as argument:


rng debian-qt-kde@lists.debian.org

After rng started you see a table with all bugreports against the packages of the KDE team. To find potentially solved or unreproducible bugs, click on the last column header to sort the list by the date of the last action. The date of the last action is the date where the bugreport received it’s last mail (including control@b.d.o mails). You will see that there are quite a lot bugs which haven’t been touched for more than two years. Many of them don’t have a unreproducible or moreinfo tag. If you want to help the KDE team, you can now start trying to reproduce the bug. If that’s not possible you can tag them with moreinfo and unreproducible. If there is no reply in roughly one month or so it’s probably safe to close this bug.

To quickly find a lot of other candidates to close one can use the filter of rng. Just enter moreinfo in the filter and the table will reduce to all bugreports containing this word or tag. Now you can again sort this list by date of last action and you will see quite a lot bugs bugs where more info was requested but no action took place for more than one year. Those need to be inspected, but probably quite a few of them are safe to close.

This example shows how filtering and sorting can greatly help to find certain bugs and support bug triaging. But please: don’t carelessly close very old bugs! Read the reports and try to reproduce them, find matching bugreports in upstream’s BTS and ask the submitter if in doubt.

Reportbug finally has a GUI!

It’s good to see that reportbug 4 finally has a graphical user interface — it’s GTK, but nobody’s perfect :)

Anyways, I’m really glad to see reportbug aiming to improve it’s usability.

Reportbug finally shows all the bugreports for a package in a list which is easily filterable. So when you’re confronted with a huge list of bugreports but searching for a specific problem, you can just enter a few letters in the filter and the buglist will shrink immediately. This missing feature was basically the most important reason why I developed reportbug-ng: Users are expected to don’t report bugs which are already filed against a package, but the main tool which was used back then to report the bugs didn’t make this task trivial. Now it does and it’s a good thing!

reportbug and reportbug-ng

Compared to reportbug-ng, reportbug shows the bugreports of a package in a tree-view, while rng shows them in a table-view. The difference is that reportbug could theoretically group serveral bugs together, like merged bugs. It currently only uses this feature to group bugs of the same severity and status. Rng does that by coloring the lines. Unfortunately in reportbug all nodes are collapsed by default, which is not very usable since you have to expand every node in order to see all bugreports. This costs the user several clicks in order to see all bugreports.

It’s also not possible to sort the bugs via the columns of the table, e.g. sort by date of last action which I think is a huge feature in order to quickly find certain kind of bugs (old bugs, bugs sorted by date of last activity) — but that’s probably easy to fix.

Another good news is that Reportbug now brings it’s own editor so the user is not forced anymore to use an console based- and maybe unfamiliar editor to compose his bugreport. This is a huge step forward regarding usability. It also moves the concept of writing a mail to the BTS a bit more away from the user which is a good thing. Maybe the BTS will support an alternative way to receive bugreports in the future so mail clients may become superfluous for reporting bugs.

Under the hood reportbug still parses the HTML from http://bugs.debian.org/ go gain the bugreport instead of the BTS’ SOAP interface. This coupling is of course dangerous since even the smallest change in the BTS webdesign could break reportbug. But SOAP support is already on the todo list of reportbug’s devs. I can only encourage this step, when reportbug-ng moved away from HTML-parsing to SOAP the actual amount of work it took was much less then I thought, I think it took me just one or two days and as a result there is python-debianbts which provides a bridge between the SOAP interface and Python.

In summary I think this is an important improvement for reportbug. There are still some minor issues like the welcome screen always showing, the nodes collapsed by default and the columns not beeing sortable but those are small issues and easy to fix. I’m very happy to see this improvement, since it will motivate the not so tech-savvy folks to report bugs, and more bugreports will ultimately lead to a better distribution.

Good work guys!

Tags

Version 1.2 of reportbug-ng now shows the tags of a bug if available. This was long overdue. Now you can for example, quickly search your bugs for the ones with the moreinfo-tag set and sort the resulting list by the date of the last action. This should give you a quick overview of bugs which may need some action (eg. another reminder to the submitter) or can potentially be safely closed.

rng-tags.png

In the next step I’ll improve the filter of rng and add a context menu which will allow to manipulate the tags of one or more bugreports and send all the changes in a single mail to control@bugs.debian.org.

Gettext and QT4?

Dear Lazyweb,

do you know how to translate QT4 applications with gettext? Looks like QT4 now uses it’s own mechanism (lupdate -> .ts -> linguist -> .ts -> lrelease -> .qm) for translating strings, which makes things a bit complicated if the rest of your application (the non GUI part) still uses gettext.

The background is — as some of you may have noticed — that rng’s GUI isn’t properly translated anymore since the switch from QT3 to QT4. I don’t know if I just should adopt QT4′s translation mechanism, but for now it would be very nice if I just could use my .po files for the QT4 stuff.

Rng 1.0 in unstable

I’ve finished the porting of rng from qt3 to qt4 and uploaded it to unstable. It has some minor regressions compared to the qt3 version, like the localization of the qt4 widgets which isn’t working yet and that the column which sorts the table isn’t saved and restored properly on startup, but it closes many other bugs and it doesn’t crash anymore.

The new version doesn’t bring so much new features so far, but since it’s using much of the stuff which came with QT4, like the QTableModel and the QWebView, it runs much faster in many cases, e.g. when sorting or filtering the table.

Ah, and last but but not least: thanks to WebKit rng even passes acid1 and acid2. Doesn’t yet pass acid3 but I guess someone is already working on it :)

rng passing acid2