41573 2021-12-15 08:54:42 +0300 Объединение через gear изменений в пакете от разных ментейнеров без сборки в репозиторий 2021-12-16 12:24:33 +0300 1 1 2 Infrastructure Infrastructure girar unspecified x86_64 Linux NEW P5 enhancement --- 1 rider placeholder glebfm ldv rider viy cas oldest_to_newest 206062 0 rider 2021-12-15 08:54:42 +0300 Есть предложение придумать схему, по которой некритичные для пакета изменения (вроде исправления URL) можно было бы закоммитить в gear без сборки пакета (или со сборкой, но без выкладывания в репозиторий). Это позволит осуществлять незначительные изменения без нагрузки на систему хранения и сборки пакетов. Такие измененения могли бы делать только approved ментейнеры. Конкретный пример - у нас около 4000 URL в репозитории нужно поправить с http на https или обновить homepage. Хорошие URL важны, т.к. по ним часто идентифицируют пакет и его версию - например в той же repology.org https://repology.org/repository/altsisyphus/problems Т.е. - фактически этот FR можно было бы рассматривать как своебразную реализацию pull request в пакет, когда изменения уже объединены, но ещё не попали в релиз. 206090 1 viy 2021-12-16 11:54:18 +0300 Здесь та проблема, что не нужно спешить решать техническими методами социальную проблему. для repocop ее аналогом была генерация патчей для пакета. Проблемы были следующие: 1) данные нельзя прикладывать как есть, нужен feedback. Те же исправления URL, как понимаю, были получены механически из базы repology, и в свою очередь, содержат какой-то малый процент (к примеру, 1%) ошибок (к примеру, URL валидный, но относится к другому схоже названному проекту). 2) ряд людей просто забивает на предлагаемые изменения, так что нужен механизм, позволяющий как-то провести эти изменения в пакеты. Т.е. если это будет фон (на ваш пакет есть патчи (как было с repocop) или pull реквесты (предлагается, чуть менее универсально, так как есть srpm заливаемые пакеты, правильнее и то, и другое) то будет та же проблема, что и с repocop - игнорирование. Если же придумать некий механизм в incoming, заставлять реагировать, в стиле "Вася Пупкин, его сестра Маша и робот repology повесили на ваш пакет patch/pull request в виде патча или коммита. Мы не пропустим ваш пакет, пока вы не отреагируете: обработаете / пошлете" то не окажется ли это гораздо большим раздражителем для людей, чем та же процедура https://www.altlinux.org/Mass_NMU ? 206092 2 viy 2021-12-16 12:19:29 +0300 пример. патчи висят в фоне, игнорируются. http://repocop.altlinux.org/pub/repocop/reports/diff/by-leader/rider/ 206093 3 viy 2021-12-16 12:24:33 +0300 (Ответ для viy на комментарий #1) > Если же придумать некий механизм в incoming, заставлять реагировать, > в стиле "Вася Пупкин, его сестра Маша и робот repology повесили на ваш пакет > patch/pull request в виде патча или коммита. Мы не пропустим ваш пакет, пока > вы не отреагируете: обработаете / пошлете" то не окажется ли это гораздо > большим раздражителем для людей, чем та же процедура > https://www.altlinux.org/Mass_NMU хотел бы пояснить. Если пытаться реализовать механизм pull реквестов, то он в значительной мере дублирует багзиллу, но мы же не заставляем людей проверкой вида "Мы не пропустим ваш пакет, пока вы не обработаете баг в багзилле" так и абстрактные pull реквесты от кого попало форсировать нельзя. В случае же MassNMU вопрос выносится на общее обсуждение, и аргументом для его форсирования является коллективное суждение по итогам обсуждения, что массовое изменение полезно и применить его нужно.