Hi,

Right now there's no clean way for a Debian derivative to close bugs
specific to their distro in a changelog entry and then distinguish
those from Debian bugs.

I'd like that developers from derivatives would get involved in this
discussion so that we can get a general solution for everyone, as I
think Debian should be responsible for providing the infrastructure
to do that.

As an example, say package foo_1.0-2 is in Debian, then distro Naibed
takes it and modifies some stuff and gets versions foo_1.0-2naibed1
and foo_1.0-2naibed2. If this distro wants to automatically parse
the changelog for version tracking or when including a mix of changelog
entries from Debian and Naibed at upload time, then it needs a way to
distinguish the bugs from versions <= 1.0-2 (Debian specific) to the
ones from versions >= 1.0-2naibed1 (Naibed specific). We cannot assume
that Naibed will not use 'unstable' as the target suite, though.

Hi Guillem,

On Tue, 2006-11-14 at 08:11 +0200, Guillem Jover wrote:

Yes, "for a Debian derivative".

Absolutely. It's in the interest of the derivatives.

I don't think that the Debian project should lead this discussion.

How many derivatives currently automatically parse the changelogs to
update their bug tracking systems? Maybe only Ubuntu, I'm not sure.

A solution for the derivative. Or for multiple derivatives if they
agree on using the same solution. I don't think it's a solution for
Debian.

On Tue, 14 Nov 2006, Bart Martens wrote:

We are the origin of the tools, and we are the "upstream" for them, so
*yes*, we are to be part of, and maybe even lead this discussion.

It will make my life as a DD easier when maintaining my Debian packages
where I want to merge from other debian-based distros, or if we have a
cross-distro co-maintenance of a package...

This is, as usual, something we better join in so that a good-for-everyone
solution is found and implemented before it results in too many work for all
involved.

On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote:

Neat.

Presumably Debian should REJECT uploads with an Origin: field other than
"debian", no?

Would it be more pleasant to have something like:

instead?

Would it be worth requiring:

or

for Debian uploads?

Cheers,
aj

-----BEGIN PGP SIGNATURE-----

Anthony Towns wrote:

Might be nice, on the other hand...

...wouldn't something like this amount to having

in .changes. This might actually be desirable and would be already
implemented in dak?

Wouldn't the benefit be deminished by dch et al. producing changelog
entries suited for upload to Debian by default?
If derivatives change this, their packages woudln't go into Debian anyways.

On Wed, 15 Nov 2006 01:59:52 +1000, Anthony Towns
azure.humbug.org.au> said:

Manoj Srivastava wrote:

Another thing: Whatever you do, don't do it on stable or security builds
will end up in the void.

Regards,

Joey

On Tue, Nov 14, 2006 at 08:11:01AM +0200, Guillem Jover wrote:

FTR, the syntax agreed upon for Launchpad (and thus Ubuntu) is:

LP: #xxx

which is not arbitrary or ambiguous like fixes vs. closes.

I don't see a problem with the approach we've chosen for Launchpad (which
will also cover several Ubuntu derivatives).

Likewise, I think that qualifying it with the distribution name is perfectly
OK; that's already unique enough.

Guillem Jover skrev:

[...]

(With my Ubuntu, not my Debian hat on)

While closing bugs will the by far most usual action, we do also want to
have the ability to relate an upload to a specification or similar in
Launchpad, which is why we don't think a "Closes:" syntax alone is enough.

What are your thoughts on this matter?

- tfheen

Guillem Jover skrev:

They are just strings. But, as I wrote, they are just one example; we
would probably want to associate uploads and bzr branches as well. The
LP syntax could be LP: #123 for closing bugs, LP: spec $specname for
associating with a spec, and LP: bzr $product/$branchname (or something
similar) for associating bzr branches with an upload.

Specs generally aren't implemented by a single upload, so it would be
Spec-related or something like that.

I would rather just have a namespace allocation and derivatives can do
whatever they want within their namespace, but to a certain degree I see
why this is problematic and it seems you are unhappy with that?

- tfheen