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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
