Ако сте следили развитието на PostgreSQL през последните няколко години, вероятно сте чували термина commitfest manager няколко пъти. Вероятно вече знаете какво е commitfest, но защо има мениджър? Тъй като през миналия януари прекарах доста време в управление на такъв, ще обясня.
Пач е приложен по време на commitfest
В основата си PostgreSQL commitfest е просто колекция от пачове, които очакват интегриране в кодовата база на PostgreSQL. Принципът на работа на commitfest е, че всяка корекция, която е изпратена на pgsql-хакери трябва да се преразглежда своевременно; след като бъде прегледан и ревизиран достатъчно пъти, корекцията е кандидат за постоянно включване в PostgreSQL от комитър.
Що се отнася до работния процес на commitfest:всяка нова корекция започва живот в commitfest в състояние „необходим преглед“; може да бъде затворено като „отхвърлено“ (разбивайки крехкото сърце на автора), „отдадено“ (правяне на деня, седмицата или месеца на автора) или „върнато с обратна връзка“ (при което авторът трябва да продължи, знаейки какво да направите, за да подобрите корекцията и да я възкресите в бъдещ комитфест). Има и краткотраен статус, „изчакване на автора“, който се използва за бърза обратна връзка, която се очаква да доведе до нова версия на корекцията след няколко дни отново като „нуждае се от преглед“. Докато имаме някои неща, маркирани като „ангажирани“ и авторите получават добра обратна връзка, нещата вървят напред:PostgreSQL расте, се развива и съзрява, за да стане следващото „основно издание“.
Дотук добре.
Защо имаме нужда от мениджър?
Управление на commitfest
Внимателният читател може да е забелязал, че има три групи хора, участващи в процеса:автори на кръпки, рецензенти, сътрудници. Има много припокриване между тези три групи, откъдето започват проблемите. За да направят добър преглед на ниво код, хората трябва да разберат кода, а тези, които го правят, също пишат свои собствени пачове. От друга страна, committers са просто рецензенти, за които се предполага, че имат по-добри способности за намиране и коригиране на „проблеми“ с кода. Committers също пишат свои собствени пачове през цялото време.
Проблемът е, че ако авторът на кръпка продължи да работи изключително върху собствените си пачове, той няма да има време да прегледа или закачи пачове на други хора. Това може да се случи лесно, ако получат обратна връзка и незабавно работят върху друга версия, което води до повече обратна връзка; това създава цикъл, който може да продължи много дълго. В даден момент, правилното нещо, което трябва да направите, е авторът да изхвърли корекцията от commitfest и да работи върху прегледа на нечий друг пластир; но тъй като всеки вярва, че техните лепенки са много важни, това рядко се случва спонтанно.
Това е мястото, където мениджърът на commitfest влиза в картината. Една от задачите е да съберем интереса от страна на pgsql-хакери към действително преглеждане на пачове. През повечето време изпращането на публични имейли до групата е достатъчно, за да накара хората да четат, обсъждат, тестват, мислят за пачове. Често на авторите на пачове трябва да се напомня, че трябва да гледат пластири на други хора, а не само своите. Приложението commitfest има удобен интерфейс за изпращане на имейл, който може да се използва за това. Тези неща обикновено са достатъчни, за да се създаде добро количество кръстосани прегледи.
Има едно старо, почти забравено правило:ако авторът на корекция не прави рецензии, техните пачове могат да бъдат затворени от commitfest без допълнително обмисляне. Доколкото знам, това никога не се е случвало, което означава, че поне до известна степен авторите на пачове са „добри граждани“.
По този начин, било то чрез убеждаване или принуда, мениджърът на commitfest може да накара хората да преглеждат пачове, което най-често няма да се случи спонтанно, освен когато хакерите вече работят в сътрудничество.
От друга страна, авторите на пачове понякога оставят своите пачове, за да се задържат без актуализации. Един възможен отговор е просто да ги затворите „върнати с обратна връзка“, но през повечето време си струва да подтикнете автор да изпрати актуализирана версия.
Мениджърът на commitfest също може да прекарва доста време в правене на собствени рецензии и ако има привилегии за извършване на commit, да пуска пачове.
И накрая, отговорност на мениджъра на commitfest е да гарантира, че всички пачове са затворени, когато commitfest приключи, което обикновено трябва да бъде един месец след началото му. За пачове, които са получили обратна връзка, на които авторът е отговорил с друга версия, е справедливо да „преместите корекцията към следващия commitfest“:обещанието на commitfest (да даде обратна връзка) е спазено. Въпреки това, да правите това с пачове, които не са получили обратна връзка, е несправедливо. Закриването на commitfests става по-трудно, когато това се случи.
Комитфестът от януари 2016 г.
Тази диаграма илюстрира комитфеста от януари 2016 г. Данните са от изпратените от мен имейли за седмично състояние:начало, седмица 1, седмица 2, седмица 3, седмица 4, финал.
Можете да видите, че започнахме с 85 със статус „нуждае се от преглед“ или „готови за извършване“, което означава, че са чакали някой друг освен автора да действа. Една седмица по-късно свалихме до 71 корекции за тези състояния:това означава, че 14 корекции бяха обработени за една седмица, което не е лошо, защото, ако се запази, този процент означаваше, че цялата опашка за корекции ще приключи само за още 5 седмици.
Въпреки това, през тази първа седмица направих шест тривиални кръпки. Те се изчерпват доста бързо и се очаква процентът на ангажимент да намалее. За щастие, други committers работиха усилено и можете да видите, че процентът на ангажираните пачове е почти постоянен за целия период. Вероятно е възможно да се постигне това във всички commitfests, ако приемем, че се прилага подходящо убеждаване към committers.
Вижда се, че статусът „върнат с обратна връзка“ се появи само в края на commitfest. Той до голяма степен продължава тенденцията, наблюдавана в линията „изчакване на автора“. Според мен това е наред. Някои хора биха предпочели определени пачове да бъдат „заредени“ рано, така че усилията да бъдат насочени към пачовете, които наистина имат шанс да влязат („триаж“, ако желаете). Аз самият не съм сигурен в това, така че не приложих тази идея тук.
Мисля, че този commitfest беше умерено успешен при въвеждането на пачове; напредъкът в този фронт със сигурност беше видим, ако не непременно огромен. Също така мисля, че беше изключително успешно да се гарантира, че всеки автор на кръпка получи известна дискусия за своите пачове. Така че от моя страна съм доволен от свършената работа.
Съвет към бъдещите мениджъри на commitfest
Мисля, че седмичните актуализации на статуса дават добри резултати:създават на всички впечатлението, че нещо се случва (което е), мотивира както рецензентите, така и поетите лица да си вършат работата.
Освен това възприех подхода да изброявам няколко кръпки, нуждаещи се от внимание всеки път – не едни и същи кръпки всеки път, а по-скоро се фокусирах върху различен набор всеки път, за да се уверя, че всеки закъсал кръпка получи някъде. Това е фина работа:би било по-лесно просто да изброите всички кръпки, които се нуждаят от внимание, но ако го направите, очите се изцъкват над гигантски списъци и всичко продължава да се игнорира.
Ще бъдат оценени всякакви мнения, които имате относно това как е бил управляван commitfest; моля, изпратете ми имейл, ако не искате да го публикувате публично като коментар. Ако смятате, че нещата, които направих, бяха неефективни, или ако имате други идеи какво да правя, готов съм да те изслушам. Възможно е да управлявам други commitfests в бъдеще, ако ресурсите позволяват.
И накрая, подгответе се за предстоящия commitfest през март 2016 г. Това ще бъде последният комитфест за 9.6 и съм сигурен, че ще има какво да прави за всички. Приятно преглеждане на пластира!
