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.
At first glance, I liked this idea in general, but some of the details
make me wonder if the same concept implemented as a patch tracker separate
from the BTS would work better. I'm still not sure, though, so some
thinking out loud about the pros and cons.
The points of convergence, where using the BTS as a patch tracker does
save duplication of effort:
* The BTS already has an established state-tracking mechanism and we don't
have to reproduce that logic. That potentially (with some development
work) gives us the ability to keep track of which patches are in which
versions without redoing that work, which is very nice. Also you get
things like tagging for free.
* Existing infrastructure in terms of web site, submission address, and so
forth so that no one has to set up a new site.
However, against that, I'd want the following features in a patch tracking
system that would need to be developed separately even if we use the BTS:
* Automatic tracking of new patches that show up in Debian packages
without requiring explicit maintainer action to open and track the patch
as a bug. Without this, I'm just not sure this will happen, even if we
have the best of intentions. I'm not sure we can raise the level of
effort across the whole distribution to manually track patch divergences
without more automated tools.
* Automatic updating of patches on new uploads that have merged them with
upstream, and automatic dropping of patches that are no longer present.
We do get some of the latter by using the BTS and Closes:, but the
automatic updating on merging is as important, I think, and there's
nothing in the BTS to deal with that.
* As others have pointed out, easy downloading of the last verison of the
patch.
Also, these aren't bugs in the Debian package, but rather bugs in upstream
(at least arguably), which put them into a different brainspace than
Debian bugs at least for me, and I'd find it awkward and confusing to have
them mixed in with Debian package bugs. That means that I'd want a
completely separate view for these, which starts looking like a separate
patch tracker.
I think that for this to work, we need to do something as automatic as
possible, and any solution that's based on asking Debian package
maintainers to do additional steps is going to struggle. Also, just as a
general rule of thumb, one never wants to keep the same information in two
separate places unless they can be automatically synchronized, which to me
argues for making automatic management of the patch tracking system
mandatory. Anything that's manual runs the risk of quickly drifting out
of date as a maintainer doesn't have time to keep it updated with the
current status of the package, which can end up being confusing enough to
have negative utility.
Of course, having it in the BTS means that anyone can help easily if they
see that things are out of date, and that's a strength. But if we can
somehow drive the process from uploaded packages rather than from any
manual action, we can enforce up-to-date status of the patch tracker.
Your proposal certainly means less up-front development work, but more
ongoing developer work, with the hope that would be reduced over time with
better tools. I think, but I'm not at all sure, that we would do better
with something that starts entirely automatic and guaranteed to be
comprehensive, but possibly not with the best quality output (such as
without nicely split-out patches), and with the possibility for the
maintainer to use or introduce tools to improve the quality of the output.
I do want to highlight this paragraph:
> For all the maintainers who already keep on top of forwarding their
> changes upstream, this won't be much of a burden; ideally you just CC
> the BTS and add some pseudoheaders. For ones who can't, because they
> cannot communicate with upstream (for whatever reason), it gives them a
> way to communicate with other interested parties (users, other distros)
> and maybe resume communication with upstream in the future. Maintainers
> who make more patches than they have time to send to upstream will have
> a problem, and might get other people filing bugs against their package
> about that, which actually helps them deal with the problem. It seems a
> win-win all the way around.
because I think that's a great summary of the advantages of having a patch
tracking system, whether implemented in the BTS or not. Most of my
trepidation is about an implementation detail of whether to use the BTS
itself or something similar but much simpler that shares certain
properties. I think the basic idea of having a site where all the current
upstream divergences of any Debian package are clearly documented and
tracked independent of having to grab Debian source packages is *great*.
The mental model I had was something more like the patch patch that I put
together for gtimer upstream once upon a time [1], except more
automatically driven. For example, I'm putting more and more of my
packages in Git repositories, and I follow a very standard naming
convention for branches. I'd love a patch tracking system that could
periodically look at my Git repository (or at the Git repository in an
uploaded v3 git package) and extract the upstream differences from bug/*
and feature/* branches and the reasons for those divergences from the
commit headers (or some other metadata tracking; I'm still not entirely
happy with using git commit --amend to change the documentation of a patch
when I'm not changing the patch).
[1] http://www.eyrie.org/~eagle/software/patches/
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: