Pokud sledujete vývoj PostgreSQL posledních několik let, pravděpodobně jste slyšeli termín commitfest manager párkrát. Pravděpodobně už víte, co je to commitfest, ale proč je tam manažer? Vzhledem k tomu, že jsem loni v lednu strávil hodně času správou jednoho, vysvětlím to.
Oprava použita během commitfest
Ve své podstatě je Comitfest PostgreSQL pouze sbírkou oprav čekajících na integraci do základny kódu PostgreSQL. Principem commitfestu je, že každý patch, který byl zaslán pgsql-hackerům musí být přezkoumána včas; jakmile bude patch dostatečně zkontrolován a revidován, je kandidátem na trvalé zahrnutí do PostgreSQL ze strany komisora.
Co se týče pracovního postupu commitfestu:každý nový patch začíná život v commitfestu ve stavu „potřebuje revizi“; může být uzavřena jako „odmítnutá“ (zlomí autorovo křehké srdce), „zavázaná“ (udělující autorovi den, týden nebo měsíc) nebo „vrácená se zpětnou vazbou“ (přičemž autor v ní musí zůstat, protože ví, co udělat pro vylepšení patche a jeho vzkříšení v budoucím commitfestu). K dispozici je také krátkodobý stav „čekání na autora“, který se používá pro rychlou zpětnou vazbu, u níž se očekává, že za několik dní bude opět výsledkem nová verze opravy jako „potřebuje kontrolu“. Dokud máme některé věci označené jako „odhodlané“ a autoři dostávají dobrou zpětnou vazbu, věci se hýbou dál:PostgreSQL roste, vyvíjí se a dospívá, aby se stal dalším „hlavním vydáním“.
Zatím je to dobré.
Proč potřebujeme manažera?
Správa commitfest
Pozorný čtenář si mohl všimnout, že do procesu jsou zapojeny tři skupiny lidí:autoři patchů, recenzenti, zadavatelé. Mezi těmito třemi skupinami se hodně překrývá, což je místo, kde začínají problémy. Aby lidé mohli dělat dobré recenze na úrovni kódu, musí kódu rozumět a ti, kteří to dělají, také píší vlastní záplaty. Na druhou stranu, komitátoři jsou jen recenzenti, u kterých se předpokládá, že budou mít lepší schopnosti při hledání a opravě „problémů s kódem“. Zadavatelé také neustále píší své vlastní patche.
Problém je v tom, že pokud autor oprav pokračuje v práci výhradně na svých vlastních opravách, nebude mít čas zkontrolovat nebo odevzdat opravy jiných lidí. To se může snadno stát, pokud obdrží zpětnou vazbu a okamžitě pracují na jiné verzi, což má za následek více zpětné vazby; to vytváří smyčku, která může trvat velmi dlouho. V určitém okamžiku je spravedlivé, aby autor vypustil patch z commitfestu a pracoval na revizi patche někoho jiného; ale protože každý věří, že jejich patche jsou velmi důležité, zřídka se to stane spontánně.
To je místo, kde do obrázku vstupuje manažer commitfestu. Jedním z úkolů je získat zájem lidí z pgsql-hackerů o skutečné přezkoumání záplat. Posílání veřejných e-mailů skupině většinou stačí k tomu, aby lidé četli, diskutovali, testovali a přemýšleli o opravách. Často je třeba autorům patchů připomenout, že se musí podívat na patche jiných lidí, nejen na své vlastní. Aplikace commitfest má praktické rozhraní pro odesílání e-mailů, které k tomu lze použít. Tyto věci obvykle postačují k vytvoření velkého množství křížových recenzí.
Existuje staré, téměř zapomenuté pravidlo:pokud autor patche neprovádí recenze, jeho patche mohou být uzavřeny z commitfestu bez dalšího zvažování. Pokud je mi známo, nikdy se to nestalo, což znamená, že autoři patchů jsou alespoň do určité míry „dobří občané“.
Ať už je to přesvědčováním nebo nátlakem, manažer commitfestu může přimět lidi, aby zkontrolovali patche, což by většinou nenastalo spontánně, s výjimkou případů, kdy hackeři již spolupracují.
Na druhou stranu autoři patchů někdy nechávají své patche bez aktualizací. Jednou z možných odpovědí je jednoduše je zavřít „vrácené se zpětnou vazbou“, ale většinou stojí za to přimět autora, aby zaslal aktualizovanou verzi.
Správce commitfestu může také strávit spoustu času prováděním vlastních recenzí, a pokud má oprávnění k odevzdání, může zadávat patche.
Nakonec je odpovědností správce commitfestu zajistit, aby byly všechny patche uzavřeny, když commitfest skončí, což by normálně mělo být jeden měsíc po jeho zahájení. U patchů, které obdržely zpětnou vazbu, na kterou autor odpověděl jinou verzí, je spravedlivé „přesunout opravu na další commitfest“:slib commitfestu (poskytnout zpětnou vazbu) byl dodržen. Dělat to však patchům, které neobdržely žádnou zpětnou vazbu, je nespravedlivé. Když k tomu dojde, je uzavření commitfestů obtížnější.
Leden 2016 commitfest
Tento graf znázorňuje leden 2016 commitfest. Údaje pocházejí z týdenních stavových e-mailů, které jsem odeslal:začátek, týden 1, týden 2, týden 3, týden 4, finále.
Můžete vidět, že jsme začínali s 85 ve stavu „potřebuje revizi“ nebo „připraveno k pověření“, což znamená, že čekali na někoho jiného, než je autor, aby jednal. O týden později jsme u těchto stavů klesli na 71 patchů:to znamená, že 14 patchů bylo zpracováno za jeden týden, což není špatné, protože pokud by se to udrželo, znamenalo by to, že celá fronta oprav by skončila za pouhých 5 dalších týdnů.
Nicméně během prvního týdne jsem provedl šest triviálních oprav. Ty se vyčerpají docela rychle a očekává se, že míra odevzdání se sníží. Naštěstí ostatní komitátoři tvrdě pracovali a můžete vidět, že míra odevzdaných záplat byla po celé období v podstatě konstantní. Pravděpodobně je možné toho dosáhnout ve všech komitfestech, za předpokladu, že se na komity použije vhodné přesvědčování.
Je vidět, že stav „vráceno se zpětnou vazbou“ se objevil až na konci commitfestu. Do značné míry pokračuje v trendu „čekání na autora“. Podle mého názoru je to v pořádku. Někteří lidé by upřednostňovali, aby byly určité patche „nabootovány“ brzy, aby se úsilí soustředilo na patche, které skutečně mají šanci se dostat (“třídění”, chcete-li). Sám si tím nejsem jistý, takže jsem tuto myšlenku zde nepoužil.
Myslím, že tento commitfest byl středně úspěšný v získávání záplat; pokrok v této frontě byl jistě viditelný, ne-li nutně obrovský. Také si myslím, že to bylo velmi úspěšné při zajištění toho, že každý autor patche měl dostatek diskuzí o svých patchích. Takže z mé strany jsem s odvedenou prací spokojen.
Rady pro budoucí manažery commitfest
Myslím si, že týdenní aktualizace stavu přináší dobré výsledky:dává každému dojem, že se něco děje (což je), což motivuje jak recenzenty, tak zadavatele, aby dělali svou práci.
Také jsem zvolil přístup, kdy jsem pokaždé uvedl několik patchů, které vyžadují pozornost – ne pokaždé stejné patche, ale spíše jsem se pokaždé zaměřil na jinou sadu, abych se ujistil, že každý zastavený patch bude někde kopat. Je to důvtipná práce:bylo by snazší vypsat všechny patche vyžadující pozornost, ale pokud to uděláte, oči se zalesknou nad obrovskými seznamy a vše bude nadále ignorováno.
Jakékoli vaše názory na to, jak byl Commitfest řízen, oceníme; prosím napište mi, pokud to nechcete zveřejnit jako komentář. Pokud si myslíte, že věci, které jsem udělal, byly neúčinné, nebo pokud máte jiné nápady, co dělat, jsem ochoten naslouchat. Pokud to zdroje dovolí, mohu v budoucnu spravovat další commitfesty.
Konečně se připravte na nadcházející Commifest v březnu 2016. Bude to poslední commitfest pro 9.6 a jsem si jistý, že pro každého bude spousta práce. Hodně štěstí při kontrole patche!