Mailing list management as a barrier to entry of young developers

Sarah Novotny, member of the governing board of Microsoft's Linux Foundation, raised question about the archaism of the Linux kernel development process. In Sarah's opinion, using a mailing list (LKML, Linux Kernel Mailing List) to coordinate kernel development and patch submissions discourages young developers and is a barrier to new maintainers. As the size of the kernel and the pace of development increase, the problem with shortage maintainers capable of supervising kernel subsystems.

Creating a more modern mechanism for communicating between maintainers and developers, similar to the “issues” system and pull requests on GitHub with the acceptance of patches directly in Git, would allow younger maintainers to be involved in the project. The current mail-order development management process is perceived by many young developers as archaic and unnecessarily time-consuming. Currently, the main working tool of core developers is the mail client, and newcomers who came to the industry 5-10 years ago and are accustomed to modern collaborative development systems find it very difficult to adapt to such an organization of work.

The discomfort is exacerbated by stringent letter formatting requirements, some of which were adopted 25 years ago. For example, in a mailing list there is a ban on the use of HTML markup, despite the fact that most mail clients use such markup by default. An example of the difficulties that arise from this is a colleague who, in order to submit a patch to the OpenBSD mailing list, which also does not allow letters in HTML, needed to install a separate mail client, since his main mail client (Outlook) sends letters in HTML.

In order not to break the established foundations and not break the habits of existing developers, it is proposed to create a mode for new developers, which allows patches to be transferred directly to maintainers via pull requests or systems similar to "issues", and automatically broadcast them to the LKML mailing list.

Another idea is to offload LKML from patches in favor of discussions and announcements. In its current form, thousands of letters go through LKML, most of which are directly proposed for inclusion in the core code and only a small part of the announcements explaining the essence of patches and discussion. Published patches are still reflected in Git and are usually accepted using pull requests in Git, while LKML only documents the process.

Source: opennet.ru