PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Zarządzanie kolejnym Commitfestem PostgreSQL

Pisałem już o zarządzaniu commitfestem PostgreSQL.

Podczas cyklu rozwojowego PostgreSQL 13 zrobiłem to ponownie. Tym razem zastosowałem inną strategię, głównie dlatego, że czułem, że doszło do nadmiernego nagromadzenia bardzo starych łatek, którym nie poświęcono wystarczającej uwagi. Więc poza poprawkami błędów (które zawsze są specjalnymi przypadkami), skupiłem się na łatkach, które od dłuższego czasu czekały w kolejce.

Jedną z rzeczy, które zauważyłem, jest to, że niektóre łatki nie zostały zaktualizowane na podstawie opinii lub rotacji bitów, nawet po wielokrotnym nakłanianiu przez poprzednich menedżerów commitfest. Zostają przeniesieni z jednego festiwalu do drugiego bez żadnej innej aktywności. Niektóre z nich pochodzą od ludzi, którzy przeszli od rozwoju PostgreSQL; inne mogą być porzuconymi projektami. Moim zdaniem nie ma sensu ich trzymać, jeśli nic się nie dzieje, więc zamknąłem je i udostępniłem listę, aby inni mogli się przyjrzeć i przejąć na własność, jeśli tego chcą. (Post uzupełniający zawiera więcej). Mam nadzieję, że jeśli ktoś jest zainteresowany tymi funkcjami, odbierze łatki i prześle je ponownie po ustosunkowaniu się do wszelkich opinii i gnicia bitów.

Inną rzeczą, która staje się powszechna, jest to, że wiele łatek pozostaje z niewielkimi recenzjami — a czasami nawet z gruntowną recenzją, nigdy nie docierają do punktu, w którym osoba przeprowadzająca testy je odbiera. W niektórych z tych przypadków moje podejście polegało na zachęcaniu konkretnych osób, które moim zdaniem mogłyby pomóc w przeglądzie; w innych przypadkach po prostu sam przejrzałem łatki. Czasami samo zadanie pytania wydaje się wystarczyć, aby zaangażować innych w dyskusję, więc nawet jeśli bezpośredni wkład jest niewielki, ma to pożyteczny większy efekt.

Sam też zapisałem się jako recenzent/komiter dla kilku poprawek. Odniosłem w tym umiarkowany sukces, kończąc na 24 zatwierdzeniach i 10 wpisach do zatwierdzeń oznaczonych jako popełnione… lub około 25% całkowitej liczby popełnionych wpisów do zatwierdzeń. Nieźle, co?

W moim e-mailu z raportem zamknięcia zamieściłem następującą tabelę:

Stan tydzień 1 tydzień 2 tydzień3 tydzień 4 końcowy
Wymaga przeglądu 165 138 116 118 0
Czekam na autora 30 44 51 44 0
Gotowy do zatwierdzenia 11 5 8 11 0
Zwrócony z opinią 1 4 5 5 28
Przeniesiono do następnego CF 2 4 4 4 191
Zobowiązana 14 23 32 34 42
Odrzucono 1 1 1 1 1
Wycofane 4 9 11 11 12

Warto zwrócić uwagę na to, że „zwrócony z informacją zwrotną” pozostawał przez cały czas na dość niskim poziomie i podskoczył tylko na samym końcu, i to na dużą skalę. Ćwiczeniem, które sugeruję przyszłym CFM, jest zdrowe zamykanie nieaktywnych, zgniłych łatek pod koniec ich mandatu, zamiast przenoszenia takich łatek na następny commitfest. Ta ostatnia operacja powinna być zarezerwowana dla łatek, które były aktywne podczas CF, lub tych, które wciąż obowiązują, lub tych, które dopiero niedawno czekały na autorów. Inną rzeczą, na którą warto zwrócić uwagę, jest liczba popełnionych łatek… a raczej to, jak powoli rosła. Niektórzy autorzy byli rozproszeni przez pomoc w wydaniu Postgres 12; inni byli bardzo aktywni w łatach, których nie część spotkania. Spodziewam się, że następnym razem kilku autorów będzie zwracać większą uwagę, a wtedy zobaczymy rzeczywisty postęp.

Bot commitfest Thomasa Munro jest nieocenionym narzędziem; autorzy łatek powinni zwrócić na to większą uwagę. Byłoby znacznie lepiej, gdyby ta usługa została zintegrowana z infrastrukturą naszej społeczności; Myślę, że to wymaga tylko kilku okrągłych sukienek.

Kilka rzeczy, które chciałbym mieć:

  • zaktualizowany pg_dump danych commitfest do lokalnego zapytania.
  • Uzyskiwałem zrzuty co tydzień, pytając właściwą osobę i napisałem kilka prymitywnych zapytań. Być może moglibyśmy dostarczyć wyniki (ulepszonych wersji) takich zapytań, takich jak raporty w aplikacjach.
  • Przydałoby się też ulepszone filtrowanie w aplikacji commitfest.
  • Akt przenoszenia łatek masowo do następnego CF może być lepiej zautomatyzowany.

Podsumowując, był to bardzo satysfakcjonujący miesiąc i mam nadzieję, że był cenny dla rozwoju PostgreSQL. Jestem wdzięczny za to, że 2. kwadrant dał mi możliwość spędzenia tego miesiąca… ale mimo to nie mogę się doczekać powrotu do moich zwykłych obowiązków.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Najważniejsze rzeczy do monitorowania w PostgreSQL — analiza obciążenia

  2. Jak używać pętli for SQL do wstawiania wierszy do bazy danych?

  3. postgresql zwraca 0, jeśli zwracana wartość ma wartość null

  4. Wybrać pierwszy wiersz w każdej grupie GROUP BY?

  5. Określanie OID tabeli w Postgresie 9.1?