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

Re: divergence from upstream as a bug



Russ Allbery wrote:
> 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.

Sure (and I really appreciated this mail).

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

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.


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.

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

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.)

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.

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.)

> * As others have pointed out, easy downloading of the last verison of the
>   patch.

Seems like something we should have in the BTS anyway, since we have
patches in the BTS for lots of other reasons already.

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

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.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


Reply to: