Moving forward
The Linux kernel was started by a university student, and there have been strong ties between the kernel and academic communities ever since. This collaboration is beneficial both to Linux, which gains from the work and ideas of researchers, and to the research community, which is able to work with a heavily used kernel and see its ideas deployed in practice. This collaboration is worth preserving -- and, indeed deepening. The incident described in this paper is seen by some developers in both camps as a threat to that collaboration, but it need not turn out that way.
We have two specific recommendations designed to ensure that the kernel project and UMN can continue to work together successfully in the future:
- UMN must improve the quality of the changes that are proposed for inclusion into the kernel, and
- The TAB, working with researchers, will create a document explaining best practices for all research groups to follow when working with the kernel (and open-source projects in general).
The combination of these two changes, we hope, will help the kernel and research communities to work together fruitfully and prevent incidents like this from occurring again.
Development process changes
In the past, the kernel community has often had to deal with a pattern of low-quality patches originating from a single company or group. These patches consume scarce maintainer time and, over time, lead to tense relations between the two groups. In such cases, the kernel community has worked with the companies involved to set up internal procedures to make the patch creation and submission process work better. When set up properly, such a process can reduce the mentoring load on kernel maintainers and enable contributors to be more successful in their work.
A common practice in many companies is to designate a set of experienced internal developers to review and provide feedback on proposed kernel changes before those changes are submitted publicly. This review catches obvious mistakes and relieves the community of the need to repeatedly remind developers of elementary practices like adherence to coding standards and thorough testing of patches. It results in a higher-quality patch stream that will encounter fewer problems in the kernel community.
We believe that UMN could benefit from a review process of this type, and recommend that UMN find at least one experienced developer to fill this role. Having such a reviewer in place could have prevented the submission of many of the flawed patches described here. Working with an experienced developer can also help UMN researchers toward better interactions with the kernel community and would, hopefully, prevent concepts like the "Hypocrite Commits" project from getting beyond the idea stage.
Until such a review process is put into place, it will be difficult to re-establish the trust between UMN and the kernel community, and patches from UMN will continue to find a chilly reception. If UMN needs help to find such a developer or to set up an internal review process, the TAB will be glad to assist. This is a role the TAB has played with many groups in the past.