the BTS gains a remote bug tracking feature for free !

Wed May 3 09:56:32 UTC 2006

  Hi developers,

  Like many of you may have noticed, a quite big mail was processed by
the BTS today [1]. 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
again [0].

  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 bts-link-upstream at lists.alioth.debian.org for
    the usertags it sets. ([2] holds all the information on how to see
    those tags).

  * thanks to aj, you can use [3], which is a tag to bugs map of the
    bts-link-upstream at lists.alioth.debian.org usertags.

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
appropriate bug).

3. WHAT'S NEXT
   ~~~~~~~~~~~

  Basically, there is many things to do [6]:

  * 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 [4].
      (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
    project.

  How to Help:

      A bts-link project has been created on alioth. The code is in the
    svn, it's written in python [5].

      You can also help me to make the btslink.cfg more complete and
    know about more bugzillas [7]

      There is also (Cc-ed) a devel mail list[8], where you can submit
    bugs, whishlist items, ...

Cheers,
------------------------------------------------------------------------

  [0] 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
      bootstraped.

  [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245339;msg=90

  [2] http://lists.debian.org/debian-devel-announce/2005/09/msg00002.html

  [3] http://bugs.debian.org/~ajt/madcoder-upstream-link

  [4] http://people.debian.org/~madcoder/examples.html

  [5] http://svn.debian.org/wsvn/bts-link/trunk/

  [6] http://svn.debian.org/wsvn/bts-link/trunk/TODO?op=file

  [7] http://svn.debian.org/wsvn/bts-link/trunk/btslink.cfg?op=file

  [8] bts-link-devel at lists.alioth.debian.org
      http://lists.alioth.debian.org/mailman/listinfo/bts-link-devel

-- 
·O·  Pierre Habouzit
··O                                                madcoder at debian.org
OOO                                                http://www.madism.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/bts-link-devel/attachments/20060503/b598f2f8/attachment.pgp