Subject: divergence from upstream as a bug
Date: Saturday 17th May 2008 21:01:08 UTC (over 8 years ago)
What if we just decide that changes made to upstream sources 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. Other tags and BTS data can be used if desired. For example, "divergence fixed-upstream", "divergence wontfix", "divergence help". Versioning information can be used to track when an upstream version resolves the divergence. Discussion and updated patches can be CCed to the bug log. The BTS could be enhanced to allow opening a bug and forwarding it upstream in a single message. (IIRC currently, it takes two). This would allow a very simple workflow where a DD makes a change to a package, generates a patch, and sends it upstream while also recording the divergence in the BTS. There would also be scope for other workflows, as well as automated tools. If a package has a debian/patches, some of which have been forwarded upstream and some not, then a tool could query the BTS (or headers in the patches, whatever) to figure out which have yet to be sent upstream, and send them. Tools could also do this for changes recorded in a VCS. For QA, a tool could compare the divergences recorded in the BTS with the source of the package and warn developers about unrecorded divergences, and divergences whose patch doesn't appear in the package's source (due to the patch being accepted upstream, or being changed after being sent to the BTS). 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. Of course it means that every package is insta-buggy, but we can deal with getting those bugs recorded piecemeil. Looking over my packages, I think I could get all their current divergences recorded in the BTS within the week. (And if it would help to have a concrete example of this proposal, I volenteer to do that.) PS, I don't want to give the wrong impression: I don't think that this would have avoided the openssl disaster, and this email is not a reaction to that. -- see shy jo  Specifically, changes outside debian/, and changes inside debian/ that result in the upstream source being patched, or add stuff like man pages that should really be added upstream.  Or attempt to win Bubulle's contest by filing them all now, also fine by me.