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

[Andrey Savchenko <bircoph@altlinux.org>]

[-- 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 --]