Bug 41573

Summary: Объединение через gear изменений в пакете от разных ментейнеров без сборки в репозиторий
Product: Infrastructure Reporter: Anton Farygin <rider>
Component: girarAssignee: 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 вопрос выносится на общее обсуждение, и аргументом для его форсирования является коллективное суждение по итогам обсуждения, что массовое изменение полезно и применить его нужно.