Wpis z mikrobloga

Jak wiecie Google jakiś czas temu ubiło swoją społecznościówkę, nawet nie płakałbym po niej gdyby nie to, że
całkiem sporo ludzi zajmujących się Linuksem wrzucało tam swoje przemyślenia. W związku z tym postawiono
w domenie people.kernel.org miniplatformę blogową dla developerów kernela:

https://people.kernel.org/monanalzłem?sieuricon/introducing-people-kernel-org

Co tam ciekawego znalazłem? A no taki właśnie post o tym czym możnaby zastąpić w przyszłośći LKML(Linux Kernel
Mailing List):

https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains

Jeśli ktoś nie wie o co chodzi z tym 'mailing list' to już wyjaśniam, bo to może być zaskoczeniem dla javascriptowych
cool kids z tagu #programista15k ( ͡° ͜ʖ ͡°) Linux nie jest rozwijany na Githubie/Gitlabie czy tam w innej Dżirze - rozwój
Linuksa odbywa się przy pomocy klienta e-mail.

Tak, dobrze rozumiecie - klonujesz repo, piszesz patcha i wysyłasz go na listę mailingową.

Następnie trzeba poczekać na review, ACK od opiekuna danego fragmentu kernela, wciągnięcie do repo opiekuna,
później do linux-next, w którym odbywa się integracja różnych podsystemów, a na końcu patch wpada do repo Linusa.

Cały proces jest wyjaśniony w detalach tutaj:
https://www.kernel.org/doc/html/latest/process/2.Process.html

Dlaczego Linux nie używa Githuba? Bo przy tej ilości kodu, ludzi i szybkości zmian Github się nie skaluje:
https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

Tutaj jeszcze wideo od Grega, jednego z najważniejszych maintainerów:
https://www.youtube.com/watch?v=L8OOzaqS37s
tl;dw: https://lwn.net/Articles/702177/

Żeby to jakoś podsumować, Linux jest rozwijany przy pomocy emaili - narzędzia z epoki kamienia łupanego,
ale o dziwo sprawdza się to wyjątkowo dobrze przy tej skali projektu. Niestety ma ono swoje bolączki i pytaniem
jest jak długo będzie się ono jeszcze skalować. Nie wykluczone, że kiedyś rzeczywiście pojawi się narzędzie
podobne do opisane w artykule(link2), które trochę ucywilizuje proces rozwoju kernela.


#linux
  • 8
@Godid1951: Microsoft ma największe repo gita na świecie. 300G ich kodu, aż musieli specjalny system plików zrobić żeby to działało.
https://vfsforgit.org/

@yggdrasil: parcha nie ( ͡° ͜ʖ ͡°) patcha tak, jakieś 3 tygodnie czekania, ale to nie jest nic niezwykłego i masz ostrzeżenie w dokumentacji, że to tyle może trwać. Mnie to jakoś nie dziwi, zobacz jaka ogromna ilosc zmian wchodzi co release, 15k commitów pomiędzy
@yuim: Autokorekta ( ͡° ͜ʖ ͡°)

Co do patcha to wrzucenie 4 zmian zajęło 10 miesięcy, spowodowane było to domeną mojego maila (serio). Ogólnie o ludziach, którzy tam rządzą nie mam zbyt dobrego zdania (to delikatnie mówiąc).

Co do CI to chodzi mi o to, że jak wrzucam patcha to on powinien się automatycznie zbudować i przetestować. W kernelu muszę sobie czekać aż jakiś developer łaskawie odpisze
W kernelu muszę sobie czekać aż jakiś developer łaskawie odpisze co innego niż jazdy na mojego pracodawcę i teksty w stylu "Get the f* off with this code, we don't want that bug fixed by your f**** company." Ja naprawdę podziękuję za takie coś. ;)


Nie znam sprawy więc ciężko mi się wypowiedzieć, zwykle za takimi akcjami kryje się długa historia wrzucania crapu do kernela.

Co do CI to chodzi mi