Trac support

Thanks to the preliminary work from Sanghyeon Seo (aka sanxiyn) bts-link has now a Trac support[1]. Sadly, there is no way in Trac to follow Duplicates like I do for bugzilla. I think I'll try to develop some heuristics to guess it, but it's for later.

A lot of improvements have been made since my post on d-d-a@:

  • the changes are now incremental (meaning, you can retire a fixed-upstream tag if you feel it's not true, bts-link won't put it again) ;
  • the changes are grouped per source package, and sent to $(source_package)@packages.debian.org so that maintainers don't miss it, even if there is only usertags changes ;
  • the mail is now commented so that maintainer don't have to figure out what's going on in the commands, bts-link tells what it saw, and takes the necessary steps.

I want to polish some bits of the code, but that should be done soon, and contributions to create new backends will be welcome.

Also note that any mail bts-link send, or receive from debbugs is archived on the bts-link-upstream list on alioth.

What's next ?
  • I want to make bts-link more simple to use, so that set up a bts-link service does not need too many manual steps
  • I want to provide some tools for the Maintainers so that they can run partial pulls for their packages, or as a tool to “forward and pull” their bugs, instead of using bts(1)
  • I want to support some very widespread BTS, especially sourceforge/gforge/tuxfamily ones, the infamous IssueZilla[2], as well as mantis (other backend will be welcomed of course, but those 3 are the most used atm).
Edit :

Bts-link has now Savane (Savannah bug trackers) and IssuZilla (openoffice and a couple of projects) support.

Bts-link now supports sourceforge trackers.

Notes

[1] meaning that Maintainers forwarding bugs to some tracs will suffer from the boostraping of bts-link on their bugs, but that does not hurt a lot ;)

[2] why did they felt the compulsive need to apply s/bug/issue/g to the DTD of the bug xml output ???