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

Re: divergence from upstream as a bug

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]

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)

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.

> There would also be scope for other workflows, as well as automated
> tools. If a package has a debian/patches, some of which have been
> forwarded upstream and some not, then a tool could query the BTS (or
> headers in the patches, whatever) to figure out which have yet to be
> sent upstream, and send them. Tools could also do this for changes
> recorded in a VCS.

This goes towards having a standard header in each
debian/patches/*. The header could include the bug number for this
patch or even foreign BTS urls.


Reply to: