Monthly Archives: April 2009

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.

Migrating a project from one SVN repository to another using git-svn

… sounds probably like a stupid idea since you could just copy the repository from the old to the new location, but in this case we don’t have direct access to the repositories, only accounts with commit-access. Ahh, and we want to preserve the complete history, of course.

Ok, the plan is to use git-svn to get a copy of the old SVN repository, complete with history and then apply each commit to the new location:

Getting the old repository

git svn clone http://old/repo/
cd repo

Removing the traces of the old repository

Now we have a git repository containing the complete history of the old SVN repository. That git repository is connected to the old SVN repository via git-svn. In order to commit it to the new repository we have to remove the traces of git-svn:

# Remove the remote branch
git branch -rD git-svn
# Remove the rest
rm -rf .git/svn/

Edit .git/config and remove the svn-remote stanza

Commiting into the new repository

Now that we can connect our git repository to the new SVN location and commit all the stuff:

# Create the new repository directory if necessary
svn mkdir http://new/repo/
# Init, fetch, rebase and commit:
git svn init http://new/repo
git svn fetch
git rebase git-svn
git svn dcommit

Maybe not the most elegant solution but it works. The new repository contains everything from the old one, only the commit dates are messed up.