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

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

[Vitaly Lipatov]

В дополнение к вопросу Алексея Шабалина о прохождении Join  я хотел бы 
добавить следующие моменты.

Они о том, кого на самом деле мы приглашаем и ждём в Тим, насколько 
хорошо работает Join и насколько Тим является сообществом эгоистов.

0. Люди приглашаются в Тим для того, чтобы они могли собирать какой-то 
свой пакет («Хотите этот пакет в Сизифе — добро пожаловать в Join»), то 
есть зовём всех желающих. А дальше (даже если хотел собирать маленький 
пакет с кодом на bash), кандидат должен освоить сборку shared libs, 
программ на C++, использование meson и cmake, autotools само собой.
То есть на самом деле никто не может собирать один пакет в Сизиф, он 
предварительно должен стать полноценным мантейнером, хотя ему это может 
вовсе не нужно.

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

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

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

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

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

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

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

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

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

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

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

[Ilya Kurdyukov]

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

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

Как в других дистрибутивах это решают? (и решают ли)

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

[Leonid Krivoshein]

Привет!


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.

Re: [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.  Можно попробовать подойти к вопросу с другой стороны и попытаться 
выяснить, кто нам в тим точно не нужен.

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

[Sergey Afonin]

On Saturday 17 June 2023, Grigory Ustinov wrote:

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

Что-то идея посетила, только вот не знаю, на сколько реализуема.

Если идёт попытка обновления по @everybody, то не пропускать 
пакет сразу, а вешать его в статус EPERM на некоторое время. 
Если в EPERM пакет провисел, скажем, 4 недели (максимальный
отпуск, можно ещё пару-тройку дней добавить), и мантейнер(ы) не
дёрнулись, можно запустить на сборку в Сизиф уже по @everybody.
И можно ослабить этот механизм для тех, кто уже есть в %chengelog.
А может и не ослаблять.

-- 
С уважением, Сергей Афонин.

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

[Aleksey Novodvorsky]

ср, 21 июн. 2023 г. в 12:40, Sergey Afonin <asy@altlinux.org>:
>
> On Saturday 17 June 2023, Grigory Ustinov wrote:
>
> > P.P.S. Решения у меня для вас нет, но две идеи накинуть могу:
> > 1. Полный пересмотр системы acl. Сейчас больше 2/3 пакетов имеют
> > свободный доступ @everybody.
>
> Что-то идея посетила, только вот не знаю, на сколько реализуема.
>
> Если идёт попытка обновления по @everybody, то не пропускать
> пакет сразу, а вешать его в статус EPERM на некоторое время.
> Если в EPERM пакет провисел, скажем, 4 недели (максимальный
> отпуск, можно ещё пару-тройку дней добавить), и мантейнер(ы) не
> дёрнулись, можно запустить на сборку в Сизиф уже по @everybody.
> И можно ослабить этот механизм для тех, кто уже есть в %chengelog.
> А может и не ослаблять.

Сизиф хорош свежестью. 4 недели -- это уже тухлятина. Это медленнее,
чем сборка в p10 с тестированием. Так Сизиф будет неинтересен. 3-4
дня?
Есть и много ли примеров "плохих" сборок @everybody? Сопровождающий
может изменить ICL.
Главная наше проблема, на мой взгляд, -- привлечение новых людей в
тим. Процесс приема медленный и не очень хорошо описан.

Rgrds, Алексей


>
> --
> С уважением, Сергей Афонин.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Sergey Afonin]

On Wednesday 21 June 2023, Aleksey Novodvorsky wrote:

> Сизиф хорош свежестью. 4 недели -- это уже тухлятина. Это медленнее,
> чем сборка в p10 с тестированием. Так Сизиф будет неинтересен. 3-4
> дня?

Так речь про обновление от @everybody, когда мантейнер(ы) не делают.
3-4 точно мало, даже новогодние праздники не перекрываются. :-)
Так все просто @everybody из ACL поубирают.

-- 
С уважением, Сергей Афонин.

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Dmitry V. Levin]

On Wed, Jun 21, 2023 at 01:40:21PM +0400, Sergey Afonin wrote:
> On Saturday 17 June 2023, Grigory Ustinov wrote:
> 
> > P.P.S. Решения у меня для вас нет, но две идеи накинуть могу:
> > 1. Полный пересмотр системы acl. Сейчас больше 2/3 пакетов имеют 
> > свободный доступ @everybody.
> 
> Что-то идея посетила, только вот не знаю, на сколько реализуема.
> 
> Если идёт попытка обновления по @everybody, то не пропускать 

Идея @everybody как раз в том, чтобы пропускать.  Другими словами,
@everybody означает, что мантейнер вполне доверяет любому другому члену
Team собирать пакет в Сизиф.

К слову, на мой взгляд, имеет смысл автоматически добавлять каждого, кто
собирает пакет в качестве @everybody, в acl.  Таким образом, собравший
будет автоматически подписываться на все новые багрепорты на собранный им
пакет.


-- 
ldv

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Антон Мидюков]

21.06.2023 18:22, Dmitry V. Levin пишет:
> On Wed, Jun 21, 2023 at 01:40:21PM +0400, Sergey Afonin wrote:
>> On Saturday 17 June 2023, Grigory Ustinov wrote:
>>
>>> P.P.S. Решения у меня для вас нет, но две идеи накинуть могу:
>>> 1. Полный пересмотр системы acl. Сейчас больше 2/3 пакетов имеют 
>>> свободный доступ @everybody.
>>
>> Что-то идея посетила, только вот не знаю, на сколько реализуема.
>>
>> Если идёт попытка обновления по @everybody, то не пропускать 
> 
> Идея @everybody как раз в том, чтобы пропускать.  Другими словами,
> @everybody означает, что мантейнер вполне доверяет любому другому члену
> Team собирать пакет в Сизиф.
> 
> К слову, на мой взгляд, имеет смысл автоматически добавлять каждого, кто
> собирает пакет в качестве @everybody, в acl.  Таким образом, собравший
> будет автоматически подписываться на все новые багрепорты на собранный им
> пакет.
> 

Хорошая идея. Я за.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Yuri Sedunov]

В Ср, 21/06/2023 в 14:22 +0300, Dmitry V. Levin пишет:
> On Wed, Jun 21, 2023 at 01:40:21PM +0400, Sergey Afonin wrote:
> > On Saturday 17 June 2023, Grigory Ustinov wrote:
> > 
> > > P.P.S. Решения у меня для вас нет, но две идеи накинуть могу:
> > > 1. Полный пересмотр системы acl. Сейчас больше 2/3 пакетов имеют 
> > > свободный доступ @everybody.
> > 
> > Что-то идея посетила, только вот не знаю, на сколько реализуема.
> > 
> > Если идёт попытка обновления по @everybody, то не пропускать 
> 
> Идея @everybody как раз в том, чтобы пропускать.  Другими словами,
> @everybody означает, что мантейнер вполне доверяет любому другому
> члену
> Team собирать пакет в Сизиф.
> 
> К слову, на мой взгляд, имеет смысл автоматически добавлять каждого,
> кто собирает пакет в качестве @everybody, в acl.  Таким образом,
> собравший будет автоматически подписываться на все новые багрепорты
> на собранный им пакет.


Для начала надо бы сделать так, чтобы ACL просто работал,
железобетонно.

$ GAACL python3-module-Cython show
python3-module-Cython	aris
$ rpmqlc python3-module-Cython
* Чт мая 25 2023 Grigory Ustinov <grenka@altlinux.org> 0.29.35-alt2
- boostrap for python3.11



-- 
Yuri N. Sedunov

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 5787 bytes --]

Добрый день!

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

Есть и решают. В Gentoо правила join (там его называют recruitment),
на мой взгляд, ещё более жесткие, чем в Альте. Тем не менее,
новые люди регулярно вступают в команду. Сроки сопоставимы.

Механизмов решения проблемы сложности вклада в дистрибутив для
людей не из основной команды много, но в целом они делятся на две
группы:

1) Вклад через сторонние оверлеи (репозитории, карманы — как
угодно). Продвинутые пользователи могут туда контрибьютить или
заводить собственные. Наиболее ценные пакеты со временем попадают
в основной репозиторий, а активные разработчики таких оверлеев
набираются опыта и нередко со временем становятся полноценными
разработчиками дистрибутива, таки пройдя recruitment (join).

Насколько я знаю, подобные оверлеи есть в Arch, Ubuntu и многих
других дистрибутивах.

Недостаток этого метода в отсутствии полноценного QA в сторонних
оверляех и их регулярных разъездах с основным репозиторием.

2) Вклад посредством проксированного мейнтенерства пакета. Суть
процесса в том, что разработкой занимается внешний разработчик
(проксируемый мейнтейнер), а коммит делает член основной команды
(Team) — проксирующий мейнтейнер. Разумеется, коммитящий разработчик
несёт полную ответственность за закоммиченный код и должен его
самостоятельно рецензировать.

При этом у многих контрибьюторов популярен механизм pull-request'ов
для подобного вклада. Gentoo их реализует преимущественно с помощью
Github. Нам, очевидно, нужен будет собственный сервис, например, на
базе Gitlab или Gitea и т.п.

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

Недостаток этого метода в увеличении нагрузки на действующих
членов Team. Но если есть желающие, то почему бы и нет. В конце
концов, они могут отдать часть собственных пакетов на
прокси-мейнтенерство.

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

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

Ключевая проблема сейчас — это нехватка времени у менторов и,
в первую очередь, ревьюверов. Впрочем, нехватка времени — проблема
любого СПО проекта.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Anton Farygin]

On 21.06.2023 12:40, Sergey Afonin wrote:
> On Saturday 17 June 2023, Grigory Ustinov wrote:
>
>> P.P.S. Решения у меня для вас нет, но две идеи накинуть могу:
>> 1. Полный пересмотр системы acl. Сейчас больше 2/3 пакетов имеют
>> свободный доступ @everybody.
> Что-то идея посетила, только вот не знаю, на сколько реализуема.
>
> Если идёт попытка обновления по @everybody, то не пропускать
> пакет сразу, а вешать его в статус EPERM на некоторое время.
> Если в EPERM пакет провисел, скажем, 4 недели (максимальный
> отпуск, можно ещё пару-тройку дней добавить), и мантейнер(ы) не
> дёрнулись, можно запустить на сборку в Сизиф уже по @everybody.
> И можно ослабить этот механизм для тех, кто уже есть в %chengelog.
> А может и не ослаблять.
>
Так это и есть 4.2 стадия JOIN.

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Sergey Afonin]

On Wednesday 21 June 2023, Dmitry V. Levin wrote:

> > Что-то идея посетила, только вот не знаю, на сколько реализуема.
> > 
> > Если идёт попытка обновления по @everybody, то не пропускать 
> 
> Идея @everybody как раз в том, чтобы пропускать.  Другими словами,
> @everybody означает, что мантейнер вполне доверяет любому другому
> члену Team собирать пакет в Сизиф.

Ну я вот не против по ряду пакетов, но у меня есть желание, чтобы
спрашивали предварительно. А вдруг я тоже уже обновление готовлю 
например? А тут вдруг прилетает tested, а только сказать "а", а 
там уже "э...". Я от компьютера больше, чем на неделю, не ухожу
обычно, но если ухожу, то это может быть чисто в речку на регату.
И там не до электронной почты, хоть и есть смартфон. Так что меня
бы устроила неделя плюс запас в несколько дней. Про месяц я написал
ради счастливчиков, кто может себе позволить полный отпуск.

> К слову, на мой взгляд, имеет смысл автоматически добавлять каждого, кто
> собирает пакет в качестве @everybody, в acl.  Таким образом, собравший
> будет автоматически подписываться на все новые багрепорты на собранный им
> пакет.

Это да. Если что, удалить не долго.

-- 
С уважением, Сергей Афонин.

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Aleksey Novodvorsky]

ср, 21 июн. 2023 г. в 15:05, Sergey Afonin <asy@altlinux.org>:
>
> On Wednesday 21 June 2023, Dmitry V. Levin wrote:
>
> > > Что-то идея посетила, только вот не знаю, на сколько реализуема.
> > >
> > > Если идёт попытка обновления по @everybody, то не пропускать
> >
> > Идея @everybody как раз в том, чтобы пропускать.  Другими словами,
> > @everybody означает, что мантейнер вполне доверяет любому другому
> > члену Team собирать пакет в Сизиф.
>
> Ну я вот не против по ряду пакетов, но у меня есть желание, чтобы
> спрашивали предварительно. А вдруг я тоже уже обновление готовлю
> например? А тут вдруг прилетает tested, а только сказать "а", а
> там уже "э...". Я от компьютера больше, чем на неделю, не ухожу
> обычно, но если ухожу, то это может быть чисто в речку на регату.
> И там не до электронной почты, хоть и есть смартфон. Так что меня
> бы устроила неделя плюс запас в несколько дней. Про месяц я написал
> ради счастливчиков, кто может себе позволить полный отпуск.
>
> > К слову, на мой взгляд, имеет смысл автоматически добавлять каждого, кто
> > собирает пакет в качестве @everybody, в acl.  Таким образом, собравший
> > будет автоматически подписываться на все новые багрепорты на собранный им
> > пакет.
>
> Это да. Если что, удалить не долго.

Так почему бы Вам не убрать everybody по умолчанию и включать его на
время Вашего длительного отстутствия?

Rgrds, Алексей
>
> --
> С уважением, Сергей Афонин.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Anton Farygin]

On 21.06.2023 14:11, Aleksey Novodvorsky wrote:
>
>     Так речь про обновление от @everybody, когда мантейнер(ы) не делают.
>     3-4 точно мало, даже новогодние праздники не перекрываются. :-)
>     Так все просто @everybody из ACL поубирают.
>
> Не думаю. Те, кто не хочет давать свой пакет другим, уже поубирали.
>
> И снова тот же вопрос.
> Знаете ли Вы достаточно примеров, когда everybody приводил к плохим 
> результатам?
> Сравним ли вред от таких сборок с потенциальным вредом от 
> замораживания версий?

Меня больше беспокоит неподконтрольное изменение ACL в пакетах, чем эта 
история.

Например, из-за стабильной непресобираемости cups-filters слетел на 
nobody, но непересобирается он по вполне понятным причинам, а новая 
версия, которая должна собираться - ещё не вышла.

ACL это вообще не панацея.

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

[Sergey Afonin]

On Wednesday 21 June 2023, Aleksey Novodvorsky wrote:

> И снова тот же вопрос.
> Знаете ли Вы достаточно примеров, когда everybody приводил к плохим
> результатам?

Мы же сейчас о потенциальном появлении в будущем большого количества
разработчиков с небольшим опытом?

> Сравним ли вред от таких сборок с потенциальным вредом от замораживания
> версий?

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

-- 
С уважением, Сергей Афонин.

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Sergey Afonin]

On Wednesday 21 June 2023, Aleksey Novodvorsky wrote:

> Так почему бы Вам не убрать everybody по умолчанию и включать
> его на время Вашего длительного отстутствия?
 
Не знаю пока. А, может, какую репутацию придумать, чтобы разделить
тех, от кого по everybody сразу проходит, а от кого с задержкой?

-- 
С уважением, Сергей Афонин.

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Anton Farygin]

On 21.06.2023 15:29, Aleksey Novodvorsky wrote:
> Так почему бы Вам не убрать everybody по умолчанию и включать его на
> время Вашего длительного отстутствия?

а что делать с ACL тех людей, которые уже давно не принимают участия в 
разработке ?

Хорошо, когда они откликаются на почту. Но могут и не откликаться.

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Vitaly Lipatov]

Sergey Afonin писал(а) 21.6.23 15:39:
> On Wednesday 21 June 2023, Aleksey Novodvorsky wrote:
> 
>> Так почему бы Вам не убрать everybody по умолчанию и включать
>> его на время Вашего длительного отстутствия?
> 
> Не знаю пока. А, может, какую репутацию придумать, чтобы разделить
> тех, от кого по everybody сразу проходит, а от кого с задержкой?
@everybody сигнализирует, что вы будете рады любой помощи.
Если хотите модерировать, уберите @everybody и будете аппрувить любую 
сборку.

Проблема вытекает из того, что нет механизма указать, какую помощь 
мантейнер готов принять по пакету.
Если же вы хотите сегрегацию для мантейнеров, то оскорбления хуже, чем 
возможность добавления в ACL что-то типа asy !maintainer @everybody я не 
вижу.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Sergey Y. Afonin]

On Friday 23 June 2023, Vitaly Lipatov wrote:

> @everybody сигнализирует, что вы будете рады любой помощи.
> Если хотите модерировать, уберите @everybody и будете аппрувить
> любую  сборку.

А если не любой, но рад? Вылез, скажем, CVE где-то, и кто-то захотел
поправить. Или реально мелкий недочёт например. А не вот там systemd
в сборочные зависимости.

> Если же вы хотите сегрегацию для мантейнеров, то оскорбления хуже,
> чем  возможность добавления в ACL что-то типа asy !maintainer 
> @everybody я не вижу.
 
Почему сразу сегрегация и оскорбление? Например как-то формализовать
опыт. А опыт - он накапливается со временем.

-- 
С уважением, Сергей Афонин

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Sergey Y. Afonin]

On Friday 23 June 2023, Sergey Y. Afonin wrote:

> А не вот там systemd в сборочные зависимости.

То есть в установочные. :-)

-- 
С уважением, Сергей Афонин

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Dmitry V. Levin]

On Fri, Jun 23, 2023 at 10:57:14PM +0400, Sergey Y. Afonin wrote:
> On Friday 23 June 2023, Sergey Y. Afonin wrote:
> 
> > А не вот там systemd в сборочные зависимости.
> 
> То есть в установочные. :-)

А в сборочные зависимости, значит, можно? ;)


-- 
ldv

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Vitaly Lipatov]

Sergey Y. Afonin писал(а) 23.6.23 21:36:
> On Friday 23 June 2023, Vitaly Lipatov wrote:
> 
>> @everybody сигнализирует, что вы будете рады любой помощи.
>> Если хотите модерировать, уберите @everybody и будете аппрувить
>> любую  сборку.
> 
> А если не любой, но рад? Вылез, скажем, CVE где-то, и кто-то захотел
> поправить. Или реально мелкий недочёт например. А не вот там systemd
> в сборочные зависимости.
> 
>> Если же вы хотите сегрегацию для мантейнеров, то оскорбления хуже,
>> чем  возможность добавления в ACL что-то типа asy !maintainer
>> @everybody я не вижу.
> 
> Почему сразу сегрегация и оскорбление? Например как-то формализовать
> опыт. А опыт - он накапливается со временем.
Мне кажется, что было бы неплохо при таких сложных требованиях записать 
на вики полиси на обращение с вашими пакетами. Если это можно будет 
формализовать, то стоит обсуждать дополнительную группу, например.
Как я понимаю, обычно все доступы отключают, потом разрешают тем, кому 
хотят, и принимают NMU от тех, кому доверяют. И всё это не 
сигнализируется наружу.

-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Ivan A. Melnikov]

On Fri, Jun 23, 2023 at 10:36:46PM +0400, Sergey Y. Afonin wrote:
> On Friday 23 June 2023, Vitaly Lipatov wrote:
> 
> > @everybody сигнализирует, что вы будете рады любой помощи.
> > Если хотите модерировать, уберите @everybody и будете аппрувить
> > любую  сборку.
> 
> А если не любой, но рад? Вылез, скажем, CVE где-то, и кто-то захотел
> поправить. Или реально мелкий недочёт например. А не вот там systemd
> в сборочные зависимости.

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

-- 
  wbr,
    iv m.

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Denis Medvedev]

On Fri, 23 Jun 2023 22:09:26 +0300
Vitaly Lipatov <lav@etersoft.ru> wrote:

> Sergey Y. Afonin писал(а) 23.6.23 21:36:
> > On Friday 23 June 2023, Vitaly Lipatov wrote:
> > 
> >> @everybody сигнализирует, что вы будете рады любой помощи.
> >> Если хотите модерировать, уберите @everybody и будете аппрувить
> >> любую  сборку.
> > 
> > А если не любой, но рад? Вылез, скажем, CVE где-то, и кто-то захотел
> > поправить. Или реально мелкий недочёт например. А не вот там systemd
> > в сборочные зависимости.
> > 
> >> Если же вы хотите сегрегацию для мантейнеров, то оскорбления хуже,
> >> чем  возможность добавления в ACL что-то типа asy !maintainer
> >> @everybody я не вижу.
> > 
> > Почему сразу сегрегация и оскорбление? Например как-то формализовать
> > опыт. А опыт - он накапливается со временем.
> Мне кажется, что было бы неплохо при таких сложных требованиях
> записать на вики полиси на обращение с вашими пакетами. Если это
ACL asy @see_policy
будет означать: see policy на wiki по поводу этого пакета? Как такой
вариант?
> можно будет формализовать, то стоит обсуждать дополнительную группу,
> например. Как я понимаю, обычно все доступы отключают, потом
> разрешают тем, кому хотят, и принимают NMU от тех, кому доверяют. И
> всё это не сигнализируется наружу.
> 

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Sergey Y. Afonin]

On Friday 23 June 2023, Dmitry V. Levin wrote:

> > > А не вот там systemd в сборочные зависимости.
> > 
> > То есть в установочные. :-)
> 
> А в сборочные зависимости, значит, можно? ;)

Увы, от libsystemd увернуться стало совсем сложно... Хотя
да, именно systemd в сборочных не требуется. Наверное. :-)

-- 
С уважением, Сергей Афонин

Re: [devel] Отсутствие доверия к сборкам других членов Тим

[Paul Wolneykien]

В Fri, 23 Jun 2023 22:29:28 +0300
Denis Medvedev <nbr@altlinux.org> пишет:

> > > Почему сразу сегрегация и оскорбление? Например как-то формализовать
> > > опыт. А опыт - он накапливается со временем.  
> > Мне кажется, что было бы неплохо при таких сложных требованиях
> > записать на вики полиси на обращение с вашими пакетами. Если это  
> ACL asy @see_policy
> будет означать: see policy на wiki по поводу этого пакета? Как такой
> вариант?

  Не, пусть лучше сразу выводит текст перед --commit с требованием
добавить сообщение (-m), как при сборке в бранчи:

  $ ssh girar task run --commit
  ...
  текст, заготовленный мэйнтейнером пакета
  ...
  Please, read the update policy for <PACKAGE>.
  If you agree with the policy, describe this update
  using -m command line option.