[RFC] Transition tracker

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luca Falavigna wrote on 28/07/08 23:48:
>...
> * SINGLE BUG, MULTIPLE TASK
> This method was chosen for python-xml transition [1] and gfortran
> transition [2]. A single bug is filed, multiple tasks are added, one for
> each package involved.
> Pros:
> 	Common location for similar tasks
> 	Easy to track overall progress
> Cons:
> 	Every change generates bugmail for all packages involved
>         Package-specific discussion is difficult
> 	Launchpad doesn't scale well if package list is huge
> 
> * ONE PACKAGE, ONE BUG
> This method has been chosen for Perl 5.10 transition in Intrepid. Many
> bugs are filed, a bug is linked to only one package.
> Pros:
> 	No excess of bugmail
> 	Launchpad handles workload perfectly
> Cons:
> 	It's not so easy to track overall progress
>...
> I would like to receive comments from other developers and Launchpad
> hackers about the tracker idea, what is preferred method to track
> transitions or any improvement we can do to the transition process.
>...

In Launchpad, if a bug is fixed in one context but not fixed in another
context, that means there's easy work to do: the fix can be picked up
from the former, and applied to the latter. But that's not true (I
assume) for library/language transitions: it wouldn't make sense to take
the patch that fixed one package, and apply it to a package of
completely different software.

Launchpad's "bugs fixed elsewhere" list shows bugs that are fixed in one
context but still open in others, to help people share fixes. It would
be misleading for in-progress transitions to show up on that list.

So, I agree with using one bug report per package.

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIjv4q6PUxNfU6ecoRAtPtAKDFKKp5IR1fayVlT3O9Sg/w8cj7TQCgpBaJ
XmNaRKb7aJk8X60iW7v+zRw=
=zZvB
-----END PGP SIGNATURE-----