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

Re: divergence from upstream as a bug

On Sun, 2008-05-18 at 09:40 +0200, Goswin von Brederlow wrote:
> Joey Hess <joeyh@debian.org> writes:
> > What if we just decide that changes made to upstream sources[1] qualify
> > as a bug? A change might be a bug in upstream, or in the debianisation,
> > or in Debian for requiring the change. But just call it a bug.
> > Everything else follows from that quite naturally..
> >
> > The bug can be tracked, with a patch, in our BTS. The bug can be
> > forwarded upstream as the patch is sent upstream. A tag "divergence" can
> > be used to query for all such bugs, or to sort such bugs out of the way.
> I think a frequent workflow goes like this:
> 1) user reports bug  [open]
> 2) patch is added    [open, Tags: patch]
> 3) bug gets closed   [closed]
> where 2 and 3 are often just a new version being uploaded. If I
> understand you right you would add the following:
> 2b) patch is send upstream [open, Tags: patch, send-upstream]
> 3b) source diverges        [closed, Tags: divergence, send-upstream]
> 4) upstream accepts patch  [closed, Tags: divergence, fixed-upstream]
> 5) new upstream release    [closed]

s/send-upstream/upstream/ - we already have a fixed-upstream.

1 - User reports bug with a patch against upstream code
	[open, patch]
2 - maintainer forwards the patch upstream
	[confirmed, patch, upstream, forwarded]
3 - maintainer uploads divergent code with Fixed: #1234
	[fixed, divergence, forwarded]
4 - bts-link tags the report as upstream work on the issue
	 [fixed, divergence, forwarded, fixed-upstream],
	[fixed, divergence, forwarded, pending] etc.
5 - maintainer closes bug in the relevant upstream release
... time passes ...

'Tags: + upstream' would mean that the issue is an upstream issue but
without a Debian-specific patch (or fix), yet.
'Tags: + divergence' would mean that the upstream issue has been fixed
in Debian with a patch in advance of an upstream fix.

Uploading a divergent package with Fixed: would mean removing the patch
tag and changing 'confirmed' into 'fixed' (or adding fixed if confirmed
not set). As divergence implies upstream, replace 'upstream' with

In effect, divergence would be a sub-case of upstream as Fixed would be
a sub-case of Closed.

(Native packages simply use Closed: directly, as now.)

We could also specify that Fixed: cannot be used unless 'forwarded' is
already set - debchange could check for that.

> It would be nice if the changelog could indicate wether a bug is
> closed by divergence or by upstream. A new statements should be added
> for the changelog to make divergence easy to handle and document them
> machine readable in the source:
>   * Adding Debian patch foo (Diverges: #1234)
>   * Patch foo added upstream (Closes: #1234)

Assuming both refer to the same bug report, I personally prefer the
Fixes: #1234 approach:

foo (0.1.6-1) unstable; urgency=low

  * New upstream release
  * Remove patch 'patch-file-name' included upstream (Closes: #1234)

 -- Neil Williams <codehelp@debian.org>  Fri, 16 May 2008 21:29:20 +0100

foo (0.1.5-2) unstable; urgency=low

  * Add 'patch-file-name' $reason (Fixes: #1234)

> Maybe divergence could mark a bug as fixed instead of closed. For
> people that want to use divergence like you propose a bug isn't closed
> untill it is accepted upstream.

I like that idea - the bug submitter gets a notification that the upload
has fixed the bug but we continue to track the issue until the patch

As far as the bug submitter is concerned, Fixed == end of the problem. 

That may require a new column on the DDPO and a new row in the PTS so
that bugs that are Fixed but not Closed are shown separately.


Neil Williams

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

Reply to: