Publishing divergence from upstream

On Monday I attended Martin Krafft's talk, Packaging with version control systems. Martin has started a project, coordinated via, to explore work patterns for packaging and cross-distro collaboration using distributed version control systems. This is a topic that I've spent a fair amount of time on so it was interesting to see Martin's packaging work flow, and hear him discuss its evolution.

Today I attended a Bof organized by Luciano Bello. Luciano is the developer that discovered the recent OpenSSL vulnerability. The point of the BoF was to discuss ways of preventing this sort of thing from happening in the future. The vulnerability in question was introduced in a Debian-specific patch, so a good bit of the discussion centered around code review and the need to make Debian's upstream divergences more transparent.

There were quite a few in attendance that felt that the best way to publish divergences is by using a patch series, (something that recently received first class support by way of the new dpkg v3 format). I used to fall into this camp, but a blog post from Joey Hess got me to reevaluate my work flow, and I now feel pretty strongly that using a patch series is not the answer.

I switched to Git a while back and have adopted a work flow similar to Martin's with an upstream branch, a Debian packaging branch, and topic branches for each customization or bug fix. Obtaining the divergence from upstream is a simple matter of diff'ing the topic branches against the upstream branch and the entire change history is preserved. Using a patch system alone seems woefully inadequate when compared to any of the modern VCS, and generating a patch series from branches in a VCS feels like, as Martin likes to say, Yak Shaving.

I plan to subscribe to the mailing list and follow the discussions taking place there. It should be interesting.