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

[Grigory Ustinov]

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

Если речь идёт об одном никому не нужном пакете - это одно, но если от 
этого пакета хоть что-то ещё зависит, мейнтейнер должен это понимать, 
кроме всего прочего для этого самого одного пакета иногда нужен второй, 
третий.. и загадить или разломать репозиторий очень недолго. Как ни 
крути для сборки даже одного пакета человек должен быть интегрирован в 
сообщество, уметь пользоваться инфраструктурой, понимать основы альтовой 
специфики сборки пакетов и так далее по списку вплоть до shared libs 
само собой.

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

В школах и университетах приём экзаменов производится по той же схеме. 
Кого-то это тоже не устраивало и ввели ЕГЭ. К чему это привело, я 
комментировать не буду.

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

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

Именно так это и работает. Кандидат собирает пакеты, ментор аппрувит, а 
потом приходит рецензент и "диву даётся" от того, что попало в репозиторий:)

>
> 3. Нет согласия в Тим по поводу применения policy. Полиси как бы есть, 
> но они никогда не утверждены и исполняются теми, кто хочет их 
> исправлять. Есть даже механизм утверждения полиси 
> https://www.altlinux.org/Policy_Policy, но он не работает.
>
> 4. Нет механизма выявления консенсуса в Тим по тому или иному вопросу. 
> Или хотя бы фиксирования двух или трёх равноправных альтернатив. Есть 
> замаскированный технический лидер (ему всегда можно написать по адресу 
> placeholder на altlinux.org).
ldv@ ?

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

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

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

Наш секретарь пока что - это последняя надежда на то, что процедура 
джойна будет проводиться качественно, а не тяп-ляп.

P.S. От себя добавлю, что Сизиф - это и так очень нестабильная штука. 
Снижение порога входа в тим не сделает его лучше. Моя практика 
показывает, что не каждый кто подаёт заявку на джойн вообще способен 
быть мейнтейнером. Есть люди, которые ошибаются, думают, что поддержка 
пакетов - это раз-два и обновил, а там оказывается надо и искать 
информацию и разбираться в коде и понимать autotools само собой.

P.P.S. Решения у меня для вас нет, но две идеи накинуть могу:
1. Полный пересмотр системы acl. Сейчас больше 2/3 пакетов имеют 
свободный доступ @everybody. Если мы планируем снижать планку для 
кандидатов, то надо отказываться от @everybody. Начать можно с деления 
на группы типа @perl @python @go.

2.  Можно попробовать подойти к вопросу с другой стороны и попытаться 
выяснить, кто нам в тим точно не нужен.