|| ||Pierre Habouzit <madcoder-AT-debian.org>|
|| ||the BTS gains a remote bug tracking feature for free !|
|| ||Wed, 3 May 2006 11:56:32 +0200|
Like many of you may have noticed, a quite big mail was processed by
the BTS today . This was generated by a new service I'm currently
developing, called bts-link.
This tool lists every BTS bug that is forwarded to a remote Bug
Tracker. If it knows how to get a Status and possibly a Resolution (if
the Status is a closing Status), it gets them, and:
* sets upstream, fixed-upstream, wontfix tags according to the
retrieved information ;
* cannonizes the forward address ;
* sets usertags to store the current known Status/Resolution of the
bug: status-(.*) holds the upstream status, and resolution-(.*) the
resolution when available.
All this work is incremental, meaning that if the upstream bug your
bug is forwarded to does not change, it's silent.
1. HOW TO USE IT
As a Maintainer, you don't have anything special to do. I'll run it
once a day (it's manual atm because I watch it works correctly, but will
be batched at some point), and it just looks to forwarded uri's and
treats the one it understands.
Note that the script won't send useless commands, it only does the
strict minimum, and we should not *ever* have as long mails as today
So basically to trig it, you just have to set the right forward status
for your bugs.
To use the valuable information it adds, you have two ways:
* bts-link uses the user email@example.com for
the usertags it sets. ( holds all the information on how to see
* thanks to aj, you can use , which is a tag to bugs map of the
2. WHAT IT SUPPORTS
It currently only support bugzilla (which would still help kde, gnome,
X.org, linux kernel, samba, mozilla, gcc Maintainers to cite only them),
but is written so that adding new backend is not a difficult task.
Also note that for bugzilla it's able to follow 'DUPLICATE' closings
(using the forward cannonicalization to force the forward to the
3. WHAT'S NEXT
Basically, there is many things to do :
* Stage 1:
+ understand some upstreams uri aliases and to be more clever wrt
them: e.g. http://gcc.gnu.org/PRnnnnnn is in fact a bugzilla in
disguise and is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=nnnnnn
+ support more remote BTS: trac, sf.net bugrackers, ... comes to mind
+ add more and more bugzilla's to the conf
+ Make the tools more efficients using threading (the bottleneck
of the tool, is the slowness of the remotes HTTP servers).
+ Create some web pages that help to craft urls like the two on .
(those are crafted with the help of a preliminary work I did on
the kde bugs as a proof of concept a couple of weeks ago).
+ Create a btspull Maintainer-friendly version that will sets the
tags and do the forward, to avoid that work at the next cron run
(and makes the daily control mail smaller...)
* Stage 2:
Currently, bts-link is only meant as a service (called btspull) but
I'd like also to develop a btspush script, more intended to the
maintainers, that automatize the submission of a debian bug to the
upstream's remote BTS.
This is obviously ambitious, but I think teams that have to handle a
very big amount of bugs .oO( Kde, Gnome, Mozilla, X.org, ... )
really need such a tool. That's indeed the reason why I started that
How to Help:
A bts-link project has been created on alioth. The code is in the
svn, it's written in python .
You can also help me to make the btslink.cfg more complete and
know about more bugzillas 
There is also (Cc-ed) a devel mail list, where you can submit
bugs, whishlist items, ...
 I sincerely apology to the many people that got the 500ko-big
'Processed:' mail from debbugs, this was far bigger than I
expected, and won't happen again, now that the tool is
Â·OÂ· Pierre Habouzit
to post comments)