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