[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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