[devel] Отсутствие консенсуса в Тим

Пт Июн 16 13:33:05 MSK 2023

Привет!

On 6/16/23 10:22, Vitaly Lipatov wrote:
> В дополнение к вопросу Алексея Шабалина о прохождении Join  я хотел бы 
> добавить следующие моменты.
>
> Они о том, кого на самом деле мы приглашаем и ждём в Тим, насколько 
> хорошо работает Join и насколько Тим является сообществом эгоистов.
>
> 0. Люди приглашаются в Тим для того, чтобы они могли собирать какой-то 
> свой пакет («Хотите этот пакет в Сизифе — добро пожаловать в Join»), 
> то есть зовём всех желающих. А дальше (даже если хотел собирать 
> маленький пакет с кодом на bash), кандидат должен освоить сборку 
> shared libs, программ на C++, использование meson и cmake, autotools 
> само собой.
> То есть на самом деле никто не может собирать один пакет в Сизиф, он 
> предварительно должен стать полноценным мантейнером, хотя ему это 
> может вовсе не нужно.

Полноценный маинтейнер (в твоей интерпретации) должен владеть всем 
инструментарием сборки и знаниями, которые человеку могут быть совсем не 
нужны. Такие маинтейнеры Тиму безусловно важны, но затачивать логику 
джойна исключительно под них, очевидно неправильно. Иначе надо говорить, 
что ALT Linux Team -- это сообщество исключительно профессиональных 
сборщиков пакетов. Мне казалось, что этот вопрос ранее уже был решён. 
Пруф: https://www.youtube.com/watch?v=FtkwU5H9Oqo

> 0. Представители компании приглашаются в Тим, когда компания хочет 
> размещать свой продукт в репозитории (ну или наоборот их уговаривают, 
> если это Яндекс). При этом задача у такого мантейнера только одна — 
> отправлять новые версии на сборку и реагировать на проблемы. Пакет он 
> может собирать давно и для разных rpm-систем. Но нет, он должен стать 
> полноценным мантейнером.

Им предлагается, иногда мы сами собираем, если находим ресурсы. Никого 
не уговариваем, здесь интерес на их стороне в первую очередь. И как раз 
с такими проблем возникает меньше, поскольку компетенции в области 
сборки своих пакетов у них, как правило, хватает, достаточно освоить 
наши инструменты и policy.

Причём, в последнее время количество желающих заджойниться, в том числе, 
и через нашу партнёрскую сеть совместимости, значительно возросло, так 
что механизм их одобрения становится особо актуальным.

> 1. У нас нет конкретных требований к навыкам мантейнера. Есть какие-то 
> соответствия ожиданиям и соответствие уровню пакетов в Сизифе. 
> Понятно, что это сводится к субъективному мнению принимающих, которое 
> представляется как объективное или консолидированное.

Если не ошибаюсь, Георгий Курячий брался делать что-то новое по джойну в 
части дифференциации и конкретизации требований. Не знаю, чем 
закончилось. А так, видимо действует старый дефолт: если в баге на джойн 
написал, "хочу научиться собирать пакеты", то учись. Если бы написал 
"хочу опакетить скрипт на bash", возможно было бы иначе.

> 2. Институт наставников (менторов) не работает, поскольку у 
> наставников нет подмастерий, они кандидаты. Эти кандидаты каким-то 
> образом, пособирав дома свои пакеты, должны стать внимательными, 
> вобрать в себя весь недокументированный опыт (видимо, прочитав много 
> пёстрых спеков) ведения пакетов в Сизифе, уметь рассуждать о 
> преимуществах Shared Libs Policy и желательно собирать пакеты из 
> апстримного git с submodules без поддержки этого в сборочнице 
> (https://bugzilla.altlinux.org/17914).

Если у кого-то что-то с наставником не складывается, нужно искать 
другого. Постоянная смена наставников говорит о невозможности работы 
человека в команде. Но в основном опыт проблем с наставниками редкий, и, 
как правило, проблема у них в дефиците времени.

> На мой взгляд, кандидат должен иметь возможность собирать пакеты в 
> Сизиф как можно раньше (с аппрувом наставником, конечно), чтобы 
> приобрести тот самый опыт, получить больше замечаний, и прийти на 
> рецензирование уже с багажом собранных пакетов. Технически сейчас 
> такая возможность есть, но она не реализуется.

Как раз с апрувом сейчас работает, насколько я слышал. Ситуация 
получается некрасивая для Тима и неудобная для наставника. Потому что 
пакеты проверяются и апрувятся только одним наставником -- в Сизиф это 
попадает без двойной проверки, а кандидата получается динамят.

> 3. Нет согласия в Тим по поводу применения policy. Полиси как бы есть, 
> но они никогда не утверждены и исполняются теми, кто хочет их 
> исправлять. Есть даже механизм утверждения полиси 
> https://www.altlinux.org/Policy_Policy, но он не работает.

В отношении оценки работы кандидата всегда стоит разделять ошибки и 
рекомендации типа "а я предпочитаю такой вариант". Джойн не должен быть 
точкой принятия policy и наоборот, отсутствие утверждённого policy не 
должно быть препятствием для джойна.

> 4. Нет механизма выявления консенсуса в Тим по тому или иному вопросу. 
> Или хотя бы фиксирования двух или трёх равноправных альтернатив. Есть 
> замаскированный технический лидер (ему всегда можно написать по адресу 
> placeholder на altlinux.org).

Вот эта рассылка в devel@ и есть единственный механизм.

> 5. Нет механизма критики мантейнеров. Вообще вся мощь «соответствия 
> ожиданиям» направлена на кандидатов, чтобы они не прошли Join, такие 
> же требования к участникам Тим не применяются.

Ну почему, критики достаточно и здесь, и в bugzilla.

> 6. Примерно ясно, откуда берутся наставники (соглашаются добровольно), 
> не ясно, откуда берутся рецензенты (назначаются секретарём из списка, 
> в котором никого нет, потому что механизма попадания в этот список 
> нет), и не всем понятна формальная роль секретаря (что он исполняет 
> процедуру, а не принимает решения).

Рецензентов остро не хватает, сейчас это главная проблема.

> 7. Не ясно, каким образом формируется процедура приёма (Join), в том 
> числе обязанности менторов и рецензентов. Есть записанные обязанности 
> секретаря, механизма внесения изменения в которых нет. Возможно, что 
> секретарь действительно не должен иметь представления о том, как 
> собираются пакеты, это для него лишнее.
>

https://www.altlinux.org/Team/Join -- тут и по ссылкам всё есть.

IMHO:

Нынешняя парадигма джойна не приведёт к экспоненциальному росту Тима 
даже при весьма высоком спросе из-вне. У человека, быстро и легко 
прошедшего джойн, напротив, будет стимул набираться опыта и получать 
навыки в смежных областях, подтверждать их, и через ACL получать новые 
полномочия.

Нужна ступенчатость, нужно разделить навыки опакечивания, работы с 
апстримным кодом, сборки из исходников, бэкпортирования в стабильные 
бранчи, закрытия багов, CVE, итд. Сначала нужно побороться за 
количество, чтобы набрать силы бороться потом за качество.

Ну и не должны страдать десятки желающих из-за одного нерадивого ментора 
(имею ввиду конечно себя), ради которого выстроена такая стена 
недоверия. Кстати, менторство -- тоже хороший навык для тима, его можно 
давать, и нужно отзывать. Для начала я бы предложил отказаться от 
"рецензента для каждого джойна", для каждого он точно не нужен.

-- 
WBR, Leonid Krivoshein.