Jeśli śledziłeś rozwój PostgreSQL przez ostatnie kilka lat, prawdopodobnie słyszałeś termin commitfest manager kilka razy. Prawdopodobnie już wiesz, co to jest commitfest, ale dlaczego jest menedżer? Ponieważ w styczniu spędziłem dużo czasu na zarządzaniu jednym, wyjaśnię.
Łatka zastosowana podczas commitfest
W swoim sercu, commitfest PostgreSQL to tylko zbiór łatek oczekujących na integrację z bazą kodu PostgreSQL. Zasada działania commitfest polega na tym, że każda łatka wysłana do pgsql-hackerów muszą zostać poddane przeglądowi w odpowiednim czasie; po odpowiednim przeglądzie i poprawieniu poprawka jest kandydatem do trwałego włączenia do PostgreSQL przez osobę przeprowadzającą testy.
Co do przepływu pracy z commitfestem:każda nowa łatka zaczyna życie w commitfest w stanie „wymaga przeglądu”; można go zamknąć jako „odrzucony” (łamiąc kruche serce autora), „zaangażowany” (uczynienie autora dnia, tygodnia lub miesiąca) lub „zwrócony z informacją zwrotną” (przy czym autor musi się tego trzymać, wiedząc, co zrobić, aby ulepszyć łatkę i wskrzesić ją w przyszłym commitfest). Istnieje również krótkotrwały status „czeka na autora”, który służy do szybkiej informacji zwrotnej, która ma zaowocować nową wersją łatki za kilka dni ponownie jako „wymaga przeglądu”. Dopóki mamy pewne rzeczy oznaczone jako „zatwierdzone”, a autorzy otrzymują dobre opinie, sprawy posuwają się naprzód:PostgreSQL rośnie, ewoluuje i dojrzewa, aby stać się kolejnym „dużym wydaniem”.
Jak dotąd tak dobrze.
Dlaczego potrzebujemy menedżera?
Zarządzanie commitfestem
Uważny czytelnik mógł zauważyć, że w proces zaangażowane są trzy grupy osób:autorzy łatek, recenzenci, autorzy poprawek. Te trzy grupy w dużym stopniu się pokrywają i tu zaczynają się problemy. Aby zrobić dobre recenzje na poziomie kodu, ludzie muszą go zrozumieć, a ci, którzy to robią, również piszą własne łatki. Z drugiej strony, commiterzy to tylko recenzenci, którzy mają mieć lepsze umiejętności znajdowania i naprawiania „problemów” z kodem. Committerzy cały czas piszą też własne łatki.
Problem polega na tym, że jeśli autor łatek będzie nadal pracował wyłącznie nad własnymi łatami, nie będzie miał czasu na przeglądanie lub wprowadzanie poprawek innych osób. Może się to łatwo zdarzyć, jeśli otrzymają informację zwrotną i natychmiast pracują nad inną wersją, co skutkuje większą ilością informacji zwrotnych; tworzy to pętlę, która może trwać bardzo długo. W pewnym momencie uczciwą rzeczą do zrobienia jest, aby autor upuścił łatkę z commitfest i pracował nad przeglądaniem łatki innej osoby; ale ponieważ wszyscy uważają, że ich plastry są bardzo ważne, rzadko zdarza się to spontanicznie.
W tym momencie pojawia się menedżer commitfest. Jednym z zadań jest wzbudzenie zainteresowania hakerów pgsql do faktycznego przeglądania łatek. W większości przypadków wysyłanie publicznych e-maili do grupy wystarcza, aby ludzie czytali, dyskutowali, testowali, myśleli o łatkach. Często autorom łatek trzeba przypominać, że muszą patrzeć na łatki innych ludzi, nie tylko własne. Aplikacja commitfest ma poręczny interfejs wysyłania wiadomości e-mail, który można do tego wykorzystać. Te rzeczy są zwykle wystarczające do stworzenia dużej ilości recenzji krzyżowych.
Jest stara, prawie zapomniana zasada:jeśli autor łatki nie robi recenzji, jego łaty mogą zostać zamknięte z commitfest bez dalszego zastanowienia. O ile mi wiadomo, to się nigdy nie wydarzyło, co oznacza, że przynajmniej w pewnym stopniu autorzy łatek są „dobrymi obywatelami”.
Tak więc, czy to przez perswazję, czy przymus, menedżer commitfest może skłonić ludzi do przejrzenia łat, które w większości nie pojawiają się spontanicznie, chyba że hakerzy już współpracują.
Z drugiej strony autorzy łatek czasami pozostawiają swoje łatki bez aktualizacji. Jedną z możliwych odpowiedzi jest po prostu zamknięcie ich „zwrócone z informacją zwrotną”, ale w większości przypadków warto skłonić autora do przesłania zaktualizowanej wersji.
Menedżer commitfest może również poświęcić dużo czasu na samodzielne przeglądanie, a jeśli ma uprawnienia do wprowadzania zmian, na wprowadzanie łatek.
Wreszcie, obowiązkiem menedżera commitfest jest upewnienie się, że wszystkie łatki zostaną zamknięte po zakończeniu commitfest, co zwykle powinno nastąpić miesiąc po jego rozpoczęciu. W przypadku łatek, które otrzymały opinie, na które autor odpowiedział inną wersją, uczciwe jest „przeniesienie łatki do następnego commitfestu”:obietnica commitfest (przekazania opinii) została dotrzymana. Jednak robienie tego w przypadku poprawek, które nie otrzymały żadnych opinii, jest niesprawiedliwe. Kiedy tak się dzieje, zamykanie commitfestów staje się trudniejsze.
Komitet w styczniu 2016 r.
Ten wykres ilustruje commitfest w styczniu 2016 roku. Dane pochodzą z cotygodniowych wiadomości e-mail, które wysyłałem:początek, tydzień 1, tydzień 2, tydzień 3, tydzień 4, koniec.
Widać, że zaczęliśmy od 85 w statusie „potrzeby przeglądu” lub „gotowy do zmiany”, co oznacza, że czekali na działanie kogoś innego niż autor. Tydzień później zmalaliśmy do 71 łat dla tych statusów:oznacza to, że w ciągu jednego tygodnia przetworzono 14 łat, co nie jest złe, ponieważ jeśli się utrzyma, ten wskaźnik będzie oznaczał, że cała kolejka łatek skończy się w ciągu zaledwie 5 tygodni.
Jednak w ciągu pierwszego tygodnia popełniłem sześć trywialnych łatek. Te kończą się dość szybko i oczekuje się, że wskaźnik zatwierdzania spadnie. Na szczęście inni autorzy pracowali ciężko i widać, że liczba zatwierdzonych łat była prawie stała przez cały okres. Prawdopodobnie jest to możliwe do osiągnięcia we wszystkich commitfestach, zakładając, że osoby dokonujące kontroli mają odpowiednią perswazję.
Widać, że status „zwrócony z informacją zwrotną” pojawił się dopiero na końcu commitfestu. W zasadzie kontynuuje trend widoczny w linii „czekanie na autora”. Moim zdaniem to jest w porządku. Niektórzy ludzie woleliby, aby niektóre łatki zostały „uruchomione” wcześnie, aby wysiłki były skoncentrowane na łatkach, które naprawdę mają szansę się dostać („triage”, jeśli wolisz). Sam nie jestem tego pewien, więc nie zastosowałem tutaj tego pomysłu.
Myślę, że ten commitfest był umiarkowanie udany, jeśli chodzi o zatwierdzenie łatek; postęp na tym froncie był z pewnością widoczny, choć niekoniecznie ogromny. Uważam również, że odniosło ogromny sukces w zapewnieniu, że każdy autor łatek będzie miał sporo dyskusji na temat swoich łat. Więc ze swojej strony jestem zadowolony z wykonanej pracy.
Porada dla przyszłych menedżerów commitfest
Myślę, że cotygodniowe aktualizacje statusu dają dobre rezultaty:daje wszystkim wrażenie, że coś się dzieje (co jest), motywując zarówno recenzentów, jak i osoby odpowiedzialne za pracę.
Poza tym przyjąłem podejście polegające na wymienieniu kilku łat wymagających uwagi za każdym razem — nie za każdym razem tych samych łatek, ale raczej za każdym razem koncentrowałem się na innym zestawie, aby mieć pewność, że każda łatka opóźniona ma gdzieś kopniaka. To subtelna praca:łatwiej byłoby po prostu wymienić wszystkie łatki wymagające uwagi, ale jeśli to zrobisz, oczy przesłonią się po gigantycznych listach i wszystko będzie nadal ignorowane.
Wszelkie opinie, jakie masz na temat zarządzania commitfestem, będą mile widziane; napisz do mnie, jeśli nie chcesz publikować tego publicznie jako komentarz. Jeśli uważasz, że rzeczy, które zrobiłem, były nieskuteczne lub masz inne pomysły na to, co zrobić, chętnie Cię wysłucham. W przyszłości mogę zarządzać innymi commitfestami, jeśli pozwolą na to zasoby.
Na koniec przygotuj się na zbliżający się commitfest w marcu 2016 r. To będzie ostatni commitfest dla 9.6 i jestem pewien, że każdy będzie miał co robić. Miłego sprawdzania poprawek!
