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

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?

Loïc Minier

Reply to: