Administration af postliste som en adgangsbarriere for unge udviklere

Sarah Novotny, medlem af bestyrelsen for Microsofts Linux Foundation, hævet Spørgsmålet om den arkaiske natur af Linux-kerneudviklingsprocessen. Ifølge Sarah afskrækker brugen af ​​en postliste (LKML, Linux Kernel Mailing List) til at koordinere kerneudvikling og indsende patches unge udviklere og er en barriere for, at nye vedligeholdere kan tilslutte sig. Efterhånden som kernens størrelse og udviklingstempoet stiger, vil problemet med mangel vedligeholdere, der er i stand til at overvåge kerneundersystemer.

At skabe en mere moderne mekanisme for interaktion mellem vedligeholdere og udviklere, svarende til "problem"-systemet og pull-anmodninger på GitHub med vedtagelse af patches direkte i Git, ville gøre det muligt at tiltrække yngre vedligeholdere til projektet. Den nuværende e-mail-baserede udviklingsstyringsproces opfattes af mange unge udviklere som arkaisk og unødigt tidskrævende. I øjeblikket er det vigtigste arbejdsværktøj for kerneudviklere e-mail-klienten, og det er meget svært for nytilkomne, der kom til industrien for 5-10 år siden og er vant til moderne samarbejdsudviklingssystemer, at tilpasse sig sådan en arbejdsorganisering.

Ubehaget forværres af strenge krav til brevformatering, hvoraf nogle blev vedtaget for 25 år siden. For eksempel forbyder mailinglisten brugen af ​​HTML-markering, på trods af at de fleste e-mail-klienter bruger en sådan markup som standard. Som et eksempel på de vanskeligheder dette skaber, blev en kollega nævnt, som for at sende en patch til OpenBSD-mailinglisten, der heller ikke tillader HTML-mail, skulle installere en separat e-mail-klient, da hans primære e-mail-klient (Outlook) sender HTML-mail.

For ikke at bryde det etablerede grundlag og ikke overtræde eksisterende udvikleres vaner, foreslås det at oprette en tilstand for nye udviklere, der giver dig mulighed for at indsende patches til vedligeholdere direkte gennem pull-anmodninger eller systemer, der ligner "problemer", og automatisk udsende dem til LKML-mailinglisten.

En anden idé er at fjerne LKML fra patches til fordel for diskussioner og meddelelser. I sin nuværende form passerer tusindvis af breve gennem LKML, hvoraf de fleste er direkte foreslået kode til inklusion i kernen og kun en lille del er meddelelser, der forklarer essensen af ​​patches og diskussioner. Publicerede patches afspejles stadig i Git og accepteres normalt ved at bruge pull-anmodninger i Git, og LKML dokumenterer kun processen.

Kilde: opennet.ru

Tilføj en kommentar