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

Re: Tracking divergence from upstream as a bug

On Sat, 2008-05-17 at 23:01 -0400, Joey Hess wrote:
> Ben Finney wrote:
> > Care to discuss what tags you plan to use, so an attempt at consensus
> > can be made on naming the tags for this purpose?
> I'm using a "divergence" usertag, with users joeyh@debian.org and
> package@packages.debian.org (so it'll show up on my bugs page, and the
> package's bug page -- not ideal). I've done aalib so far.

Doing this retrospectively does make things look more than a little odd
in the BTS. Unarchiving, reopening, retitling, change severity and then
tagging (#97695). I can see the reasoning (keeping the patch with any
original bug report) but reopening a bug 7 years after it was closed
just to indicate that upstream still hasn't included the fix is more
than a little strange to behold.

I wonder if such divergence issues should merely start with a new bug
and *reference* the old, archived, bug report.

I need to implement divergence tags for GPE and soci - I can't decide
whether to start new bugs or reopen ones that have already been closed
by an upload.

Certainly in the future I plan to treat my own bugs more like NMUs and
if the fix involves a patch that I have devised myself, send the patch
to the BTS prior to the upload.

However, from a bug submitter point of view, I don't think I want to see
the bug report kept open (tagged divergence) after it has actually been
closed by a Debian-specific patch. As upstream it might make a fair bit
of sense but as a user / bug submitter, it will just look odd.

Also, as upstream, I might not want to trawl through hundreds of
comments (possibly including references to other packages due to bugs
being reassigned) to get to a patch and possibly find that the patch in
the BTS at comment 112 differs from the final patch actually applied
before the bug was closed in comment 234.

I'm wondering, therefore, if divergence bugs should be NEW bugs that
include only the final patch and a summary along with a reference to the
old discussion so that the old bug can stay archived and closed and the
new bug is updated via bts-link.

A user reporting a bug in foo should not still be wondering why the bug
is open after the fix has been applied. To me, divergence tags are a
maintainer issue, not a user issue and as such, could deserve being
filed by the maintainer as a separate issue. To all intents and
purposes, the bug actually reported by the submitter was fixed long,
long ago - I can't see that it makes a whole lot of sense (to the bug
submitter) to reopen it. If I got a message saying that a grave bug that
I had reported before Etch was now suddenly reopened in the release
phase for Lenny, as a bug submitter I might be a little concerned.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: