Re: divergence from upstream as a bug
On Sat, May 17, 2008, Joey Hess wrote:
> > If I grab an upstream change from their VCS, I wont open a
> > Debian bug about it; if I find a bug in the Debian version which also
> > applies to upstream, I might skip to directly reporting it upstream,
> > and only there.
> If you grab a patch from upstream that you know will be in a future
> upstream release, the divergence is temporary. You can choose not to
> file a bug report in our BTS about it, knowing that it will clear up.
> (And if you're somehow wrong, knowing that QA tools will flag that.)
> Just as, if you see a bug filed in the upstream BTS, you don't need to
> file it in our BTS. In both cases, the package in Debian *has* a bug,
> even if it's counterproductive to file it in the BTS.
So has the maintainer to decide whether to file a "divergence" bug?
What about divergences which upstream doesn't like or which are only
useful to Debian and would be hard or useless to render generic?
> > A change is a change, not a bug; we don't need to map each change to a
> > bug. We could get better at distinguishing between changes, and
> > perhaps we can reach a point where we can extract a list of logical
> > changes (or changesets) between Debian uploads, or between the Debian
> > and upstream versions, but I don't think we want bugs for that.
> The point of having bug reports is not for change tracking, but for
> communication. We've long established that we want maintainers to tell
> upstream about what changes they make. Using the BTS just exposes this
> communication to the world and allows querying it and noticing when it's
> not being done, or when upstream is ignoring it.
Concerning communication, I think we should make our patches easy to
extract and browse. Another helpful solution is the PTS: I know some
upstreams actively commenting on Debian uploads despite not using
Debian (but I don't know many).
I do see your point that the BTS can store emails, URLs, files etc.,
but I don't like diverting the use of this tool for this use case; I'd
be more happy with a separate tool. Another route could be to ask
maintainers to expose divergences at the source level; perhaps we can
standardize a format to extract a stack of patches with descriptions
(whatever format is used to store the Debian source), and a command (or
debian/rules target) to trigger this output?