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. 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'. 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 disappears. 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part