Re: divergence from upstream as a bug
Joey Hess <joeyh@debian.org> writes:
> The biggest reason for using the BTS is not technical. It's that, if we
> decide that the project will treat divergence from upstream as a bug,
> then we've effectively decided that maintainers will be responsible for
> both minimising unncessary divergence, communicating about it to
> upstream, and for keeping track of what divergence exists. Because
> developers are reponsible for their bugs. The tools that are used to do
> that are secondary to deciding (and strengthening the existing feeling)
> that ita needs to be done and that maintainers are responsible for doing
> it.
>
> And the big con of only using some sort of automated patch tracker is
> that it's effectively a decision in the other direction; that
> maintainers are not responsible for divergence, that it's something that
> just happens, uncontrollably, that upstream will have to figure out ways
> to find the useful patches on their own, and that we need to automate
> everything since people won't be working on it.
This is a really good point. I think this is one of the things I liked
about it but wasn't managing to dig out of my subconscious. I do think
any divergence between us and upstream is a bug (often an upstream bug,
but still a bug), so I like that mindset.
Some of that divergence is, realistically, bugs that won't be fixed. For
example, I patch the Shibboleth SP Makefile because I remove one XML
schema which is under a non-free license (no modification allowed).
Realistically, that upstream difference isn't ever going to go away,
because upstream isn't ever going to stop shipping that schema; they don't
care about Debian's freeness definition, at least in that context. There
are a lot of similar issues. But we could use the wontfix tag for things
like that to make the status clear.
Some of the divergence, and here I'm particularly thinking of FHS tweaks,
needs a fair bit of work to integrate upstream. I'm honestly of two minds
whether it's better to carry a simple patch in Debian to put things in the
right location or spend the effort to develop complex Autoconf plus build
system fixes to add an --enable-fhs option or the like to upstream while
maintaining backward compatibility with their traditional installation
locations, and I've run into that problem on several occasions. But I
think there too it's still reasonable to consider it a bug, just one of
those bugs that's likely to sit in the BTS for quite a long time.
> BTW, a minor pro for using the BTS is that any progress that is made in
> the BTS world is something our divergence tracking would then immediatly
> benefit from. Whether it is automatic submission of bug reports from one
> BTS to another, or tracking bug status between BTSs, or even wholly
> decentralised bug tracking.
Good point.
> I think that lintian.debian.org and other QA pages are the best model
> here. They let us spot where maintainers are not keeping up, and do the
> best we can automatically in that case, but they're no substitute for
> the maintainer actually doing their job. Just as we don't mass-bug file
> for every lintian report, we'd not want to mass-inject every divergence
> into the BTS. (Probably.)
I suppose I'd be okay with doing it manually if I had tools to do it, and
actually now that I think about it, the tools are not that hard. I expect
that writing a tool to take a Git branch and turn it into a divergence bug
with the necessary details is a matter of an hour of programming at most
plus some conventions for the commit message.
The one that I'm the most worried about is keeping the patch in the bug up
to date when things change in the Debian package. Putting it there in the
first place is already something requiring manual action, but as it gets
merged with newer versions of upstream, I'm usually not thinking about
that particular bug and having to manually update the BTS with the results
of those merges would be quite annoying.
I'd also really like it if whatever system we use could figure out on its
own when a patch was merged upstream and went away (as you address later).
It's a bit different than the usual bug closing case, which is handled
manually, in that I as a Debian maintainer generally haven't taken any
explicit action in that case; I just packaged a new upstream version and
as a side effect a bunch of my branches now no longer have differences
from upstream. But there again I can imagine tools that would make it
automatic enough for me, and none of them seem conceptually hard.
> Now, maybe it would make sense for the automated, QA side of things to
> do a best-effort generation of patches, and have a frontend (maybe in
> the packages.qa.debian.org pages?) that shows both the ones in the BTS
> and those.
I'd really like this, since among other things I think that tracking
divergence from upstream is *more* important for the packages that are the
least well-maintained and with maintainers that are the most overloaded.
> And it makes sense to automatically track when patches in the BTS are
> out of date. (This could even be useful for patches that have not been
> applied yet, not just for existing divergences.)
Oh, good point! That's a great reason to have a separate concept of
patches in the BTS where the BTS is aware of a patch as a patch.
> The state of a bug being a divergence can just be one step in the
> life-cycle of a bug.
> Consider a new bug filed one a package, which turns out to be an
> upstream bug, is forwarded upstream, gets patched in Debian, and then
> has the patch forwarded upstream, so the bug is tagged as a divergence,
> and then later upstream fixes it so the bug is closed.
Hm, yeah, that works.
Okay, the idea is growing on me more and more.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: