[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: version tracking plans?

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 control@b.d.o 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

I guess one question is how you want:


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)


Anthony Towns <aj@humbug.org.au> <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?''

Attachment: pgpENFcj2DuLQ.pgp
Description: PGP signature

Reply to: