Sarah Novotny, membre du conseil d'administration de la Linux Foundation de Microsoft,
Créer un mécanisme d'interaction plus moderne entre les mainteneurs et les développeurs, similaire au système de « problèmes » et aux pull request sur GitHub avec l'adoption de correctifs directement dans Git, permettrait d'attirer les jeunes mainteneurs vers le projet. Le processus actuel de gestion du développement par courrier électronique est perçu par de nombreux jeunes développeurs comme archaïque et inutilement long. Actuellement, le principal outil de travail des développeurs de noyau est le client de messagerie, et il est très difficile pour les nouveaux arrivants arrivés dans l'industrie il y a 5 à 10 ans et habitués aux systèmes de développement collaboratif modernes de s'adapter à une telle organisation du travail.
Ce malaise est exacerbé par des exigences strictes en matière de formatage des lettres, dont certaines ont été adoptées il y a 25 ans. Par exemple, la liste de diffusion interdit l'utilisation du balisage HTML, malgré le fait que la plupart des clients de messagerie utilisent ce balisage par défaut. Comme exemple des difficultés que cela crée, on a mentionné un collègue qui, pour envoyer un correctif à la liste de diffusion OpenBSD qui n'autorise pas non plus le courrier HTML, devait installer un client de messagerie séparé, puisque son client de messagerie principal (Outlook) envoie un courrier HTML.
Afin de ne pas briser les fondations établies et de ne pas violer les habitudes des développeurs existants, il est proposé de créer un mode pour les nouveaux développeurs qui permet de soumettre des correctifs aux mainteneurs directement via des pull request ou des systèmes similaires aux « issues », et de les diffuser automatiquement. à la liste de diffusion LKML.
Une autre idée est de décharger LKML des correctifs au profit des discussions et des annonces. Dans sa forme actuelle, des milliers de lettres transitent par LKML, dont la plupart sont du code directement proposé à l'inclusion dans le noyau, et seule une petite partie sont des annonces expliquant l'essence des correctifs et des discussions. Les correctifs publiés sont toujours reflétés dans Git et sont généralement acceptés à l'aide de demandes d'extraction dans Git, et LKML documente uniquement le processus.
Source: opennet.ru