Bug 41573

Summary:	Объединение через gear изменений в пакете от разных ментейнеров без сборки в репозиторий
Product:	Infrastructure	Reporter:	Anton Farygin <rider>
Component:	girar	Assignee:	placeholder <placeholder>
Status:	NEW ---	QA Contact:	Andrey Cherepanov <cas>
Severity:	enhancement
Priority:	P5	CC:	glebfm, ldv, rider, viy
Version:	unspecified
Hardware:	x86_64
OS:	Linux

Description Anton Farygin 2021-12-15 08:54:42 MSK

Есть предложение придумать схему, по которой некритичные для пакета изменения (вроде исправления URL) можно было бы закоммитить в gear без сборки пакета (или со сборкой, но без выкладывания в репозиторий).

Это позволит осуществлять незначительные изменения без нагрузки на систему хранения и сборки пакетов.

Такие измененения могли бы делать только approved ментейнеры.

Конкретный пример - у нас около 4000 URL в репозитории нужно поправить с http на https или обновить homepage. 

Хорошие URL важны, т.к. по ним часто идентифицируют пакет и его версию - например в той же repology.org

https://repology.org/repository/altsisyphus/problems

Т.е. - фактически этот FR можно было бы рассматривать как своебразную реализацию pull request в пакет, когда изменения уже объединены, но ещё не попали в релиз.

Comment 1 viy 2021-12-16 11:54:18 MSK

Здесь та проблема, что не нужно спешить решать техническими методами социальную проблему.
для repocop ее аналогом была генерация патчей для пакета.
Проблемы были следующие:

1) данные нельзя прикладывать как есть, нужен feedback.
Те же исправления URL, как понимаю, были получены механически из базы repology,
и в свою очередь, содержат какой-то малый процент (к примеру, 1%) ошибок (к примеру, URL валидный, но относится к другому схоже названному проекту).

2) ряд людей просто забивает на предлагаемые изменения, так что нужен механизм,
позволяющий как-то провести эти изменения в пакеты. 

Т.е. если это будет фон (на ваш пакет есть патчи (как было с repocop) или pull реквесты (предлагается, чуть менее универсально, так как есть srpm заливаемые пакеты, правильнее и то, и другое) то будет та же проблема, что и с repocop - игнорирование.

Если же придумать некий механизм в incoming, заставлять реагировать,
в стиле "Вася Пупкин, его сестра Маша и робот repology повесили на ваш пакет patch/pull request в виде патча или коммита. Мы не пропустим ваш пакет, пока вы не отреагируете: обработаете / пошлете" то не окажется ли это гораздо большим раздражителем для людей, чем та же процедура
https://www.altlinux.org/Mass_NMU
?

Comment 2 viy 2021-12-16 12:19:29 MSK

пример. патчи висят в фоне, игнорируются.
http://repocop.altlinux.org/pub/repocop/reports/diff/by-leader/rider/

Comment 3 viy 2021-12-16 12:24:33 MSK

(Ответ для viy на комментарий #1)
> Если же придумать некий механизм в incoming, заставлять реагировать,
> в стиле "Вася Пупкин, его сестра Маша и робот repology повесили на ваш пакет
> patch/pull request в виде патча или коммита. Мы не пропустим ваш пакет, пока
> вы не отреагируете: обработаете / пошлете" то не окажется ли это гораздо
> большим раздражителем для людей, чем та же процедура
> https://www.altlinux.org/Mass_NMU

хотел бы пояснить. Если пытаться реализовать механизм pull реквестов, то он в значительной мере дублирует багзиллу, но мы же не заставляем людей проверкой вида
"Мы не пропустим ваш пакет, пока вы не обработаете баг в багзилле" 
так и абстрактные pull реквесты от кого попало форсировать нельзя.

В случае же MassNMU вопрос выносится на общее обсуждение, и аргументом для его форсирования является коллективное суждение по итогам обсуждения, что массовое изменение полезно и применить его нужно.