Joey Hess <[EMAIL PROTECTED]> writes: > What if we just decide that changes made to upstream sources[1] qualify > as a bug? A change might be a bug in upstream, or in the debianisation, > or in Debian for requiring the change. But just call it a bug. > Everything else follows from that quite naturally.. > > The bug can be tracked, with a patch, in our BTS. The bug can be > forwarded upstream as the patch is sent upstream. A tag "divergence" can > be used to query for all such bugs, or to sort such bugs out of the way.
At first glance, I liked this idea in general, but some of the details make me wonder if the same concept implemented as a patch tracker separate from the BTS would work better. I'm still not sure, though, so some thinking out loud about the pros and cons. The points of convergence, where using the BTS as a patch tracker does save duplication of effort: * The BTS already has an established state-tracking mechanism and we don't have to reproduce that logic. That potentially (with some development work) gives us the ability to keep track of which patches are in which versions without redoing that work, which is very nice. Also you get things like tagging for free. * Existing infrastructure in terms of web site, submission address, and so forth so that no one has to set up a new site. However, against that, I'd want the following features in a patch tracking system that would need to be developed separately even if we use the BTS: * Automatic tracking of new patches that show up in Debian packages without requiring explicit maintainer action to open and track the patch as a bug. Without this, I'm just not sure this will happen, even if we have the best of intentions. I'm not sure we can raise the level of effort across the whole distribution to manually track patch divergences without more automated tools. * Automatic updating of patches on new uploads that have merged them with upstream, and automatic dropping of patches that are no longer present. We do get some of the latter by using the BTS and Closes:, but the automatic updating on merging is as important, I think, and there's nothing in the BTS to deal with that. * As others have pointed out, easy downloading of the last verison of the patch. Also, these aren't bugs in the Debian package, but rather bugs in upstream (at least arguably), which put them into a different brainspace than Debian bugs at least for me, and I'd find it awkward and confusing to have them mixed in with Debian package bugs. That means that I'd want a completely separate view for these, which starts looking like a separate patch tracker. I think that for this to work, we need to do something as automatic as possible, and any solution that's based on asking Debian package maintainers to do additional steps is going to struggle. Also, just as a general rule of thumb, one never wants to keep the same information in two separate places unless they can be automatically synchronized, which to me argues for making automatic management of the patch tracking system mandatory. Anything that's manual runs the risk of quickly drifting out of date as a maintainer doesn't have time to keep it updated with the current status of the package, which can end up being confusing enough to have negative utility. Of course, having it in the BTS means that anyone can help easily if they see that things are out of date, and that's a strength. But if we can somehow drive the process from uploaded packages rather than from any manual action, we can enforce up-to-date status of the patch tracker. Your proposal certainly means less up-front development work, but more ongoing developer work, with the hope that would be reduced over time with better tools. I think, but I'm not at all sure, that we would do better with something that starts entirely automatic and guaranteed to be comprehensive, but possibly not with the best quality output (such as without nicely split-out patches), and with the possibility for the maintainer to use or introduce tools to improve the quality of the output. I do want to highlight this paragraph: > For all the maintainers who already keep on top of forwarding their > changes upstream, this won't be much of a burden; ideally you just CC > the BTS and add some pseudoheaders. For ones who can't, because they > cannot communicate with upstream (for whatever reason), it gives them a > way to communicate with other interested parties (users, other distros) > and maybe resume communication with upstream in the future. Maintainers > who make more patches than they have time to send to upstream will have > a problem, and might get other people filing bugs against their package > about that, which actually helps them deal with the problem. It seems a > win-win all the way around. because I think that's a great summary of the advantages of having a patch tracking system, whether implemented in the BTS or not. Most of my trepidation is about an implementation detail of whether to use the BTS itself or something similar but much simpler that shares certain properties. I think the basic idea of having a site where all the current upstream divergences of any Debian package are clearly documented and tracked independent of having to grab Debian source packages is *great*. The mental model I had was something more like the patch patch that I put together for gtimer upstream once upon a time [1], except more automatically driven. For example, I'm putting more and more of my packages in Git repositories, and I follow a very standard naming convention for branches. I'd love a patch tracking system that could periodically look at my Git repository (or at the Git repository in an uploaded v3 git package) and extract the upstream differences from bug/* and feature/* branches and the reasons for those divergences from the commit headers (or some other metadata tracking; I'm still not entirely happy with using git commit --amend to change the documentation of a patch when I'm not changing the patch). [1] http://www.eyrie.org/~eagle/software/patches/ -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
