On Sun, 2008-05-18 at 15:30 +0200, Goswin von Brederlow wrote: > Neil Williams <codehelp@debian.org> writes: > > > > 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. Hmm, that's interesting. Good idea. This would mean a relatively simple change to implement the entire proposal: nnn-fixed@bugs.debian.org | (Fixes: #nnn) marks the bug as fixed by a patch added by Debian and awaiting a new release upstream to be finally closed. nnn-fixed is ignored if the upstream tag is not already set. Bugs can be fixed in the changelog of an upload using (Fixes: #1234) in a similar manner to (Closes: #1234). The principle usage of "fixed" is to denote points at which Debian diverges from upstream. Filenames of patch files must be clearly identified when using (Fixes: #1234) in the changelog. Possibly add: "Fixed bugs must also be tagged Forwarded as well as just upstream." or alternatively, "Forwarded is equivalent to upstream and one or both tags must be used for Fixed to work." Probably also add: "Fixed bugs must be tagged "patch" for Fixed to work." Also add: "The maintainer may choose not to post the patch to the BTS when using Fixes: as long as the upstream bug tracker makes all patches publicly visible without requiring passwords or authentication." Lintian could check that the specified patch actually exists and use that to output a warning if the patch was removed (due to the changes already being present in the upstream). The other checks implemented in debchange and in bugs.debian.org. The requirement for a filename in debian/patches is so that it is easier to track the point at which Fixes: needs to become Closes:. I suppose it might be possible to parse the output of lsdiff -z *.diff.gz | grep -v debian to find the filename of the files being patched and put those in the Fixes: changelog entry but I would prefer the use of debian/patches as one source file may contain more than one issue to be Fixed - e.g. a FTBFS bug in the #include lines and a seg fault in a function declaration in src/foo.c. YMMV. Is this acceptable as a possible policy proposal? > > 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. Well that was just the simplest way of doing things but if the PTS can be adapted to *ignore* patches where the bug is "fixed" (or at least split those numbers into a different section of the ToDo list in the PTS) then that would solve the problem by allowing everyone to clearly identify which BTS patches are in the package and which are not. Leaving the patch tag in place could be useful, as long as the relevant web pages and tools can discriminate between patches in open bugs and patches in Fixed bugs. > > 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. Yes. A tweak or two in dpkg-dev as well so that Fixes: gets into the .changes file alongside Closes: (after all, the same upload may Close some bugs and Fix others), e.g. where the Closed issue is critical / security-related and warranted an urgent upstream release but the Fixed issue(s) were minor (or disruptive) and need to wait for a later upstream release. This is no more work for those who choose not to use (Fixes: #), it simply helps those of us who want to track divergence in the BTS. The upstream element is still done via Forwarded (if desired) or merely via "upstream" - depending on the preferences of the upstream team. (e.g. as my own upstream, I may choose to still use 'upstream'.) I don't see that duplication is a major problem - it might be a hassle but you'd have the same hassle anyway by having to update the patch if the upstream changes in a way that stops the patch applying. Besides, there would be nothing requiring anyone to use Fixes: just because it is available. Nor is there any requirement (in this version) that the patch is submitted to the BTS, merely that the patch exists (as a patch file) in the .diff.gz. Large projects could easily set up simple pages that use the SOAP interface to filter bugs according to the needs of that team (as Emdebian does). The real benefit of this proposal, IMHO, is that it covers the situation where upstream doesn't use a sensible (publicly visible) bug tracker, just individual email addresses for the upstream developers. When those are forwarded, there is no way for anyone else (doing an NMU or assisting the upstream team in a non-official manner) to find out what is contained in the patch. For those teams with decent bug trackers upstream, Fixed can still be used, if you want it. With suitable changes in debchange, we could have: $ dch -a --fixes 1234 "Add 090_missing_stdlib_h.patch" ... time passes, new upstream release made... $ dch -a --closes 1234 Simple. -- 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