Re: Proposal: Handling of changelog bug closures in Debian derived distros
- To: email@example.com
- Subject: Re: Proposal: Handling of changelog bug closures in Debian derived distros
- From: Tollef Fog Heen <firstname.lastname@example.org>
- Date: Sun, 03 Dec 2006 13:59:31 +0100
- Message-id: <[🔎] email@example.com>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <20061119221245.GB5695@zulo.hadrons.org> (Guillem Jover's message of "Mon, 20 Nov 2006 00:12:46 +0200")
- References: <20061114061101.GA19408@zulo.hadrons.org> <455D05A7.email@example.com> <20061117061917.GC30721@zulo.hadrons.org> <455E1C52.firstname.lastname@example.org> <20061119221245.GB5695@zulo.hadrons.org>
* Guillem Jover
| On Fri, 2006-11-17 at 12:32:18 -0800, Tollef Fog Heen wrote:
| > 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.
| Are those the only ones you'd need for now? Could the recently "proposed"
| Vcs field help with the bzr branches or does this refer to upstream
| branches only?
Given that we (Canonical and Ubuntu) is firmly committed to bzr, our
interest in other RCS-es is not likely to be a concern.
Note that being able to associate an upload and a branch is not the
same as saying they come from the same place. As an example, we might
have a changelog entry reading:
* Integrate 8d branch for better support of 8D graphics cards.. LP:
The upload would then come from an integration branch, but we want to
create the association automatically.
| > > What about "Implements: foo" (or similar), a proper regex would have
| > > to be defined, but you get the idea.
| > Specs generally aren't implemented by a single upload, so it would be
| > Spec-related or something like that.
| Could you explain how would you use that information to associate
| things? And is there some way you would mark that spec is fully
The association would be done in launchpad, so it would not be of
concern for dpkg itself. (We would probably have the upload processor
associate the relevant meta-data with the upload based on the .changes
file and then make sure the meta-data was kept together with the other
meta-data we keep for an upload.)
I don't think we would ever want to mark spec progress in a changelog;
we discussed it, but it was rejected since progress often isn't the
result of a single upload, but rather a series of uploads of multiple
packages. I'll be happy to have this discussion further, but I think
a discussion on how Ubuntu's procedures work is getting sufficiently
off-topic for debian-project. :-)
(Another reason for wanting bug closure but not spec progress tracking
in a changelog is bugs are closed frequently; often multiple per
uploads. A person probably has somewhere in the range of 5-10 specs
for a six month release cycle; changing the status of those by way of
a web UI isn't a big overhead.)
| > 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?
| I'd prefer if we came up with something that is general and does not
| need everyone around to implement their own solution. Granted some of
| the work will still be specific per distribution, for example the
| launchpad or bugzilla hooks into dak, but such solution would minimize
| them, and most of the changes could be merged upstream w/o problem.
A problem I see with trying to make this general is we end up with a
lot of typing. The Closes syntax in changelogs is wonderful because
it's so simple. If people had to write Closes: debian/#1234 (as an
example), it'd be less readable, more writing and I think less liked
as a whole. Inside a project, bug numbers are going to be unique;
there's only one Freedesktop.org bug #1234, there's just one Debian
bug #1234 and there's just one Launchpad bug #1234, so for me it makes
a lot more sense to have a way to refer to bug #1234 in the context of
a project and then treat that as a bug closing there. It's not like
reopening bugs is that common anyway, so using a web/email UI for that
is perfectly reasonable.
If the syntax ended up being Closes: debian/#1234, Closes:
Launchpad/#1234, Closes: Freedesktop.org/#1234, the «closes» bit is
redundant and we could just as easily use Debian: #1234, LP: #1234 and
(We can argue over whether abbreviations should be allowed or not. I
think they should, overlaps should be uncommon enough that we don't
really need to care deeply.)
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :