Neil Williams <[EMAIL PROTECTED]> writes:
> On Sun, 2008-05-18 at 09:40 +0200, Goswin von Brederlow wrote:
>> Joey Hess <[EMAIL PROTECTED]> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
