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@example.com 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 <firstname.lastname@example.org> <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?''
Description: PGP signature