On Fri, Aug 15, 2003 at 07:57:52PM -0500, Colin Watson wrote: > > What happens when a package splits? Do the bugs belong to the old > > source? The new source? How's the connection made? Automatically? > > Manually by maintaining good changelogs? Manually by telling the BTS > > which bugs to carry forward, and letting the others automagically > > disappear? > Probably simplest to let this be handled in the same way as renaming of > packages is currently handled, namely that you have to sort out any > stray bugs yourself.
When you split a package (foo.deb from bar.dsc into foo.dsc), the BTS
will have:
(a) All of foo's bugs already assigned to foo, with roughly correct
binary version numbers.
(b) A changelog for foo.dsc that either includes some entries from
bar's changelog (hopefully)
So, the version tree will look like:
bar: 1.0-1 1.0-2 1.0-3 1.1-1
foo: [bar: ... 1.0-3] 1.2-1
And the binary mappings for foo.deb will look like:
foo 1.0-1 bar 1.0-1
foo 1.0-2 bar 1.0-2
foo 1.0-3 bar 1.0-3
foo 1.2-1 foo 1.2-1
I think we could manage to automate that, reasonably.
I'd rather it be automated, otherwise the bugs might get lost (not appear in
a query for pkg=foo&suite=unstable), and then archived.
> Otherwise katie'd have to send debbugs some kind of
> wonky message when it spots a package being renamed, and there'd be a
> lot of stateful complexity.
We already have both those though, really, as far as this case is concerned.
> Reassigning clears both found and fixed version lists, possibly unless
> the source and target are from the same source package. If the latter,
> this would be the one part of mail processing that knows about binary
> <-> source mappings, but that should be OK here.
Alternatively, when you receive the "foo 1.2-1 foo 1.2-1" line, you
could note the previous entries about foo talked about "foo * bar *",
and consider that a "split", and clear all the version information from
all of foo's bugs. That'd seem very, very gross to me.
Maybe a [EMAIL PROTECTED] command to let you say:
version-connect foo 1.1-3 1.2-1
would be a better way of handling this? It'd probably be possible to do
a changelog hack to have katie automate this, a la:
* Split foo.deb from bar.dsc (Takeover-Deb: foo=1.1-3)
which would let us also add some hacks to include historical versions in the
.changes, and not have to do the parsing ourselves. Can leave that for later
though.
I guess one question is how you want:
pkgreport.cgi?src=bar&version=1.1-3
pkgreport.cgi?pkg=foo&version=1.1-3
to work after a split. Should they be the same as before the split,
so that foo's bugs appear in both? Should the source package for the
latter be listed as "bar" or "foo"? I don't think we want new uploads
to change what those urls display.
Maybe that means we want source versions to be recored as:
package: foo
fixed-in: 1.1-1 bar_1.1-3
found-in: 1.0-1 1.1-2 foo_1.2-1
(with the note that versions can't include an _, and checks in the code
to ensure user submitted ones don't)
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Is this some kind of psych test?
Am I getting paid for this?''
pgp6zlyqCiXp7.pgp
Description: PGP signature
