Управление на друг PostgreSQL Commitfest

И преди съм писал за управлението на PostgreSQL commitfest.

По време на цикъла на разработка на PostgreSQL 13 го направих отново. Този път използвах различна стратегия, най-вече защото усетих, че има прекомерно натрупване на много стари пластири, които не са получили достатъчно внимание. Така че освен корекциите на грешки (които винаги са специални случаи), се фокусирах върху пачове, които стояха на опашката по-дълго.

Едно нещо, което забелязах, е, че някои пачове не са били актуализирани според обратна връзка или за гниене на битове, дори след многократно подтикване от предишни мениджъри на commitfest. Те се преместват от един commitfest на друг без друга дейност. Някои от тях са от хора, които са преминали от разработката на PostgreSQL; други може да са изоставени проекти. Според мен няма смисъл да ги държим наоколо, ако нищо не се случва, затова ги затворих и предоставих списък, така че другите да могат да разгледат и да поемат собствеността, ако желаят. (Последваща публикация съдържа още малко). Надявам се, че ако някой се интересува от тези функции, ще вземе кръпките и ще ги изпрати отново, след като отговори на всякаква обратна връзка и битово гниене.

Друго нещо, което става често срещано, е, че много кръпки се задържат с малък преглед - или понякога дори със значителен преглед никога не стигат до точката, в която комитьорът ги взема. В някои от тези случаи моят подход беше да подканя конкретни хора, които смятах, че биха могли да помогнат с прегледа; в други случаи просто сам прегледах пластирите. Понякога изглежда, че просто задаване на въпрос е било достатъчно, за да се включат други в дискусията, така че дори ако нечият пряк принос е малък, той има полезен по-голям ефект.

Аз също се регистрирах като рецензент/изпълнител за няколко пачове сам. Постигнах умерен успех в това, завърших с 24 ангажименти и 10 commitfest-записи, отбелязани като извършени... или около 25% от общия брой ангажименти на commitfest. Не е зле, а?

В имейла си с отчет за приключване публикувах тази таблица:

Едно нещо, което си струва да се отбележи, е как „върнати с обратна връзка“ остана доста ниско през цялото време и скочи само в самия край, и то с голям брой. Упражнение, което предлагам да извършат бъдещите CFM, е здравословно затваряне на неактивни, битови пачове в края на мандата им, вместо да преместват такива пачове към следващия commitfest. Последната операция трябва да бъде запазена за пачове, които са били активни по време на CF, или тези, които все още се прилагат, или тези, които са чакали авторите едва наскоро. Другото нещо, което си струва да се отбележи, е броят на поставените пачове... или по-скоро колко бавно се изкачва. Някои извършители бяха разсеяни от помага при пускането на Postgres 12; други бяха много активни в пачове, които не бяха част от commitfest. Очаквам, че няколко committers ще обърнат повече внимание следващия път и тогава ще видим известен напредък.

commitfest ботът на Thomas Munro е безценен инструмент; авторите на пластири трябва да обърнат повече внимание на това. Би било много по-добре тази услуга да бъде интегрирана в нашата инфраструктура на commitfest; Мисля, че това просто изисква няколко кръгли костюми.

Някои неща, които бих искал да имам:

• актуализиран pg_dump на данните от commitfest за локални заявки.
• Получавах сметища всяка седмица, като питах точния човек и написах някои груби запитвания. Може би можем да предоставим резултатите от (подобрени версии на) такива заявки като отчети в приложенията.
• Някое подобрено филтриране в приложението commitfest също би било добре дошло.
• Масово преместване на пластири до следващия CF може да бъде по-добре автоматизиран.

Като цяло това беше много удовлетворяващ месец и се надявам, че е бил ценен за развитието на PostgreSQL. Благодарен съм, че 2ndQuadrant ми даде възможността да прекарам месеца, правейки това... но въпреки това очаквам с нетърпение да се върна към редовните си задължения.