Re: Proposal: Handling of changelog bug closures in Debian derived distros

[Tollef Fog Heen <tfheen@ubuntu.com>]

* 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:
   bzr xorg/8d-graphics-support

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
| implemented?

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
fd.o: #1234

(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      : :' :
                                                                      `. `' 
                                                                        `-