On Sat, 16 Mar 2024 12:43:41 +0200 Dmitry V. Levin wrote: > On Thu, Mar 14, 2024 at 09:16:05PM +0300, Anton Farygin wrote: > [...] > > Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но > > имеющим некоторые ограничения в правах. А именно: > > > > - он может отправлять изменения только к тем пакетам, в ACL которых он > > присутствует; > > > > - он может отправлять новые, приналежащие @nobody или @everybody пакеты > > только после review и approve от прошедших стадию 4.2 ментейнеров; > > > > -  в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким > > ментейнером лидером устанавливается тот, кто делал approve; > > По сути речь идёт о том, что мы как team уже готовы доверить новым > кандидатам, а что - ещё не готовы. Это предложение, по видимому, неявно > постулирует, что мы готовы доверять новым кандидатам отдельные пакеты, но > не готовы сразу доверить любой пакет с открытым acl, а захочет ли и сможет > ли кандидат добиться такого доверия - это вопрос индивидуальный. Я думаю, что в данном вопросе ограничение по ACL не сильно поможет. Мы хотим в Сизифе качественный код, удовлетворяющий опеределённому уровню, а не тяп-ляп — собралось, значит и так сойдёт. Вот пример кода, который был бы в Сизифе, если бы предложенное правило работало: mv mdcat*.1* mdcat.1 xz mdcat.1 Вместо: BuildRequires: asciidoctor gem-asciidoctor Просто для понимания: вместо генерации документации из asciidoctor, её сырой исходник был переименован в man-страницу. И ментор это пропустил. Часть пакетов вообще собиралась с undefined symbol в логах. Сборочница такое бы не пропустила, но ментор решил, что кандидат готов собирать пакеты в Сизиф. Debuginfo не создавался, лицензии были неверно указаны и прочие подобные ошибки — всё это будет в Сизифе, если разрешить не прошедшим рецензирование кандидатам самим собирать пакеты в Сизиф. ACL тут не поможет, потому что ACL не повысит качество кода. Нужно повышать качество работы менторов, чтоб рецензентам не приходилось доучивать кандидатов. Best regards, Andrew Savchenko