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

Re: divergence from upstream as a bug

Loïc Minier wrote:
>  The bug tracker is a tool for me; not everything needs to go via bug
>  tracking.

I'm not thinking about using the BTS for this just because it happens to
be the hammer at hand, but instead because it looks to be a tool that
allows solving a large percentage of the requirements, and already
interoperates with other tools (including upstream BTSes and mailing lists).

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

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

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: