Zarządzanie poprzez listy mailingowe jako bariera uniemożliwiająca przyjazd młodym programistom

Sarah Novotny, członkini zarządu fundacji Linux Foundation firmy Microsoft, uniesiony pytanie o archaicznym charakterze procesu rozwoju jądra Linuksa. Według Sarah używanie listy mailingowej (LKML, lista mailingowa jądra Linux) do koordynowania rozwoju jądra i przesyłania poprawek zniechęca młodych programistów i stanowi barierę dla dołączania nowych opiekunów. Wraz ze wzrostem rozmiaru jądra i tempa rozwoju, problem z niedobór opiekunowie zdolni do nadzorowania podsystemów jądra.

Stworzenie nowocześniejszego mechanizmu interakcji pomiędzy opiekunami i programistami, podobnego do systemu „problemów” i pull requestów na GitHubie z przyjęciem poprawek bezpośrednio w Git, umożliwiłoby przyciągnięcie do projektu młodszych opiekunów. Obecny proces zarządzania rozwojem poprzez e-mail jest postrzegany przez wielu młodych programistów jako archaiczny i niepotrzebnie czasochłonny. Obecnie głównym narzędziem pracy programistów jądra jest klient poczty elektronicznej, a nowicjuszom, którzy przybyli do branży 5-10 lat temu i są przyzwyczajeni do nowoczesnych systemów rozwoju współpracy, bardzo trudno jest dostosować się do takiej organizacji pracy.

Dyskomfort pogłębiają rygorystyczne wymagania dotyczące formatowania listów, z których część została przyjęta 25 lat temu. Na przykład lista mailingowa zabrania używania znaczników HTML, mimo że większość klientów poczty e-mail domyślnie korzysta z takich znaczników. Jako przykład trudności, jakie to stwarza, podano kolegę, który aby wysłać łatkę na listę mailingową OpenBSD, która również nie pozwala na pocztę HTML, musiał zainstalować osobnego klienta poczty e-mail, ponieważ jego główny klient poczty e-mail (Outlook) wysyła pocztę HTML.

Aby nie zburzyć ustalonych fundamentów i nie naruszyć przyzwyczajeń dotychczasowych programistów, proponuje się stworzyć tryb dla nowych programistów, który umożliwi przesyłanie poprawek do opiekunów bezpośrednio poprzez pull requesty lub systemy typu „issues” i automatyczne rozgłaszanie je na listę mailingową LKML.

Innym pomysłem jest odciążenie LKML z łatek na rzecz dyskusji i ogłoszeń. W obecnej formie przez LKML przechodzą tysiące listów, z których większość to bezpośrednio propozycje kodu do włączenia do jądra, a tylko niewielka część to ogłoszenia wyjaśniające istotę poprawek i dyskusje. Opublikowane poprawki są nadal odzwierciedlane w Git i zwykle są akceptowane za pomocą żądań ściągnięcia w Git, a LKML jedynie dokumentuje proces.

Źródło: opennet.ru

Dodaj komentarz