Re: divergence from upstream as a bug
On 19/05/08 at 09:14 +0900, Charles Plessy wrote:
> 'morning Neil and everybody. So many mails to read for breakfast!
>
> Le Sun, May 18, 2008 at 03:51:18PM +0100, Neil Williams a écrit :
> > 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.
>
> Even simpler: Fixes: #nnn downgrades the severity to wishlist, adds "To
> be merged upstream:" to the subject, and sends a message saying "This
> bug has been fixed by patching the original sources; we will forward
> this patch to the upstream authors and close this bug report when
> upgrading the Debian package to an upstream source in which the patch
> has been merged or obsoleted".
Take a bug #111, severity:serious, affecting unstable,testing,stable.
The maintainer fixes the bug in unstable using a Debian patch. Following
your process, the bug is now downgraded to wishlist. Meaning that RC
#111 bug in stable suddenly became a wishlist bug. We don't want that!
Could someone summarize again the different features that we require for
the "BTS tracks patches sent upstream" thing? I can think of:
- the new features must not change the existing workflow, when not using
the BTS to track upstream patches.
- the submitter should still know when the bug is fixed in Debian (=
when he can upgrade the package and expect it to work as supposed)
- the maintainer and upstream need a way to list the patches that
were submitted upstream but not integrated yet.
- the process must not break the tracking of bugs in other suites
Anything else?
The current solution proposed by Don is:
add a divergence tags that can be used to mark bugs about patches sent
upstream ; don't archive closed bugs tagged divergence.
This is good, because it avoids duplicating all the version-tracking for
a "fixed-with-a-patch" state that will only be useful for a few
packages. Those who don't need the feature won't see it.
Two additional changes could be made as well, to help with the process:
1) add parsing for Closes-with-patch: in changelog. This closes the
bug normally, and also tags the bug + divergence. sounds
non-disruptive.
2) slightly change behaviour of Closes:. do as usual, and if the bug
is tagged divergence, remove the tag.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: