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

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

Possibly add:
	"Fixed bugs must also be tagged Forwarded as well as just

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

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



Neil Williams

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

Reply to: