Le Mer 3 Mai 2006 12:23, Alexander Sack a écrit :
> On Wed, May 03, 2006 at 11:56:32AM +0200, Pierre Habouzit wrote:
> > 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.
>
> Maybe one can make this feature push mails to me instead of
> the control@bugs.debian.org?
>
> I would like to review those changes before they get applied
> to the BTS ... at least unless I am sure it does what I want :).
* the usertags are harmless, since they are in a "private" and well
known namespace.
* the forward canonization is vital for things like tracking bugzilla's
"merges" (it in fact rewrites a $(uri)/show_bug.cgi?old_nnn into the
$(uri)/show_bug.cgi?new_nnn)
* as of tags, it only touches (like I explained) :
- upstream: ensure it's always set
- wontfix: try to guess if upstream tagged that bug wontfix, and
set/unset it accordingly
- fixed-upstream:
if the upstream status is a closing status (and that's
neither a 'Dupe' nor a WONTFIX -- since in debian
wontfix is not closing), it sets the tag, else closes it.
So I guess this does pretty well what it should. There may be some
missed 'WONTFIX' if upstream played the 'and if we changed resolutions
names ?' game, or trigger too quick fixed-upstream on some particular
cases like:
* some other DUPLICATE-like resolution (which is in fact a merge or at
least a forward to another potentially opened bug)
* resolution like the Gnome NOTGNOME resolution, which means that the
bug does not comes from the Gnome upstream. For those, the maintainer
will have to:
- reassign the bug to the right package in debian ;
- mention the Gnome bug entry ;
- remove the forward, and erroneous tags.
It's the sole cases where it may do "stupid" things. For the first one,
that can be hacked in the btslink tool so that it does not makes the
mistake again (and the next cron run will fix the tags), for the second
one, it's too "high level" to be automatized, and it'll require the
Maintainer intervention anyway, so I won't bother "fixing" that issue
more than that.
btslink will *never* close or reopen bugs. So it's pretty harmless IMHO,
this won't resurect a RC bug for which you made a debian-only patch and
that is still not fixed upstream.
So just tell me if somethings looks illogical so that I make it work in
a more sensible way. But I don't think a "validation" of the mails is
vital (especially since once bts-link has the appropriate fix, next run
will make things right again with no human intervention)
Cheers,
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpM420i7dTQL.pgp
Description: PGP signature