Bug relations, '#nnn blocked by #mmm'

[Stefan Potyra]

Hi,

Am Dienstag 07 März 2006 17:09 schrieb Brad Bollenbach:
> On 2-Mar-06, at 11:51 AM, Wouter van Heyst wrote:
> > Hi,
> >
> > kiko asked me to send a mail describing my use case for the subject.
> > It is just what made me ask currently, I haven't thought about cases
> > that need the support more.

I can add a simple use case from MOTU-land: basically any transition matches 
exactly the #nnn blocked by #mmm relationship.

Example: the (still outstanding) allegro -> allegro4.2-transition: First 
allegro4.2 needs to be synced, then some packages can be rebuilt (e.g. wing 
#33684, atanks #33679, libdumb #33672). Some packages also build-depend on 
libdumb and thus cannot be rebuilt before libdumb was rebuilt (e.g. kraptor 
#33681, rafkill #33685). 

> >
> >
> > In bzr we keep hitting unicode exceptions like #3980, #5281, #33029
> > and
> > others. To keep tab on things, a possible solution would be have a
> > metabug which is blocked by all the specific unicode problems we see.
>
> What about using keywords to arbitrarily group related bugs?

This imo doesn't exactly match the #nnn blocked by #mmm semantics, but would 
be a very nice feature indeed.

Use-cases:
currently, we (ab)use malone to mark that a MOTU is already working on a 
package by filing a bug with the title "accepted work" on a sourcepackage 
(e.g. transitions, packages with unmet dependencies - *not* for bugs already 
present in malone). That way, we create a list (with some mail-parsing of the 
bug-emails) that contains every package on which s.o. is working (see [1]). 
If grouping bugs by keywords or some tagging mechanism would be possible in 
malone itself, we wouldn't need some nasty hacks to get that very list ;).

Another use-case were the merges, which worked pretty much in a similar way 
(only that this time keybuks MoM-list was used to initially fill the list, 
see [2], [3], [4] for reference).

One thought further: Some sourcepackages fall into more than only one 
catagory. Example: during dapper merge cycle, we had to merge new debian 
versions and at the same time needed to transition packages for the libstdc++ 
allocator transition. So if a MOTU merged a new debian version, he also had 
to check if he had to do the libstdc++-transition. As written above: [2], 
[3], [4] was the hack we used at that time to easily see what needed to be 
done. 
If we could get that info directly from malone, it would be awesome. (maybe by 
tagging bugs for catagories?)


[1]: http://revu.tauware.de/~sistpoty/MoM/wip.py
[2]: http://revu.tauware.de/~sistpoty/MoM/index.py?state=new
[3]: http://revu.tauware.de/~sistpoty/MoM/index.py?state=accepted
[4]: http://revu.tauware.de/~sistpoty/MoM/index.py?state=fixed

Cheers,
	Stefan.