Bug 41573 - Объединение через gear изменений в пакете от разных ментейнеров без сборки в репозиторий
Summary: Объединение через gear изменений в пакете от разных ментейнеров без сборки в ...
Status: NEW
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: girar (show other bugs)
Version: unspecified
Hardware: x86_64 Linux
: P5 enhancement
Assignee: placeholder@altlinux.org
QA Contact: Andrey Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-15 08:54 MSK by Anton Farygin
Modified: 2021-12-16 12:24 MSK (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 вопрос выносится на общее обсуждение, и аргументом для его форсирования является коллективное суждение по итогам обсуждения, что массовое изменение полезно и применить его нужно.