This was my first ever presentation to an audience that wasn’t entirely my colleagues or fellow students. It was delivered as a lightning talk at FOSDEM 2016 and focused on the work that had been done to bring Patchwork up-to-date, after it had languished for a couple of years.
Mailing lists are the bedrock of many open source software projects, and have been so since the early days of the Internet. However, mailing lists can struggle to compete with code collaboration tools like Gerrit and Rietveld, many of which offer features such as integration with automated testing tools and patch tracking. How can such features be integrated into existing, mailing list-based projects like the Linux kernel or DPDK? The presenter reports on the ongoing work around the widely-deployed ‘patchwork’ tool to do just this.
Tracking of patches between development mailing lists and automated testing tools can be accomplished using patchwork. patchwork provides a web interface for patches submitted to mailing lists and presents them alongside any comments. patchwork also supports the tracking of the state of patches, be they Accepted, Rejected or Under Review. By design, patchwork is not intended to replace mailing lists but rather supplement them: these features are entirely optional, but where used can help ease the burden on maintainers by removing the need to perform tedious, time-consuming and low-value tasks like manual sorting. patchwork is already widely deployed for many projects, and instances can be found on kernel.org, dpdk.org and openembedded.org, to name but a few. There are also many projects, including Open vSwitch and QEMU, that can be found on ozlabs.org, which is maintained by the original author of patchwork.
This talk outlines the ongoing work to supplement development mailing lists with web-based workflows using patchwork. We demonstrate how features such as continuous integration support, automated patch and series tracking and a vastly expanded API help position the combination of the Mailing List and patchwork as a viable, feature-competitive alternative to tools such as Gerrit or Rietveld. We also detail some of the complexities of structuring the inherently unstructured data found on mailing lists. How do I identify a series of patches, for example? How do identify a reply to a patch? How do I identify a patch itself?
This talk be of particular interest to testers of open source, mailing list-based projects such as the Linux kernel, QEMU, DPDK or Open vSwitch. These users will be able take advantage of features like support for continuous integration servers and series tracking to develop automated, distributed testing infrastructures. Communities like OpenStack have shown that such infrastructures are critical for delivering software faster while reducing risk and maintenance cost. Such an infrastructure is currently being developed for the DPDK community, and it is easy to envision a similar roll-out for other projects with similar requirements.
It will also be of interest to the developers of these projects. These developers can already use patchwork as a tool to track patch backlogs, maintain personal TODO lists, or just browse submissions via a web UI/XML-RPC API. However, the new features provide these users with functionality that can help automate even more of the tedious yet necessary overhead tasks.