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

Re: divergence from upstream as a bug



Neil Williams <codehelp@debian.org> writes:

> 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
> 	[closed]
> ... time passes ...
> 	[archived]
>
> '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.

'fixed + upstream' would mean divergence. No need for a new tag actually.

> 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
> 'divergence'.

Why remove the patch tag? Well, ok, maybe it is better so you can get
a list of pending patches in your package without having already
applied patches show up.

> 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.

So what you're saying is that we only need a minimal change:

- (Fixes: #1234) in changelog when adding a patch
- The fixed state from NMU uploads is reused for divergent sources.
[- debchange does some extra sanity checking]

And we use "fixed + upstream" as source being divergent.

MfG
        Goswin


Reply to: