Re: [devel] полиси внесения существенных изменений

[Anton Farygin <rider@altlinux.com>]

Всё можно сделать гораздо проще:

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

На всё - неделя максимум. Фиксированный срок на обсуждение. Иначе мы так 
и будем полоскать друг другу нервы всё время, а процесс будет простаивать.

Я бы добавил ещё пункт, что обсуждаются только коллизии с решениями, 
интегрированными в Sisyphus. Например, нет смысла обсуждать 
работоспособность ядра Debian на Sisyphus - и так будет понятно, что оно 
без изменений работать не станет.

Правда и во всех этих схемах непонятно, как учитывать интересы различных 
сторонних проприетарных продуктов.

Aleksey Novodvorsky пишет:
> Коллеги,
> возможно, нам нужно создать полиси, регулирующую принятие решений в
> случаях, аналогичных внесению изменений в sqashfsprogs.

Тогда нам будет необходимо обсуждать необходимость обновления всех 
версий всех программ в репозитарии. Это unreal.

Пример из жизни - обновился synaptics. Сломался тачпад. Если бы мы перед 
этим обсуждали необходимость его обновления, то думаю, что мы бы никогда 
не узнали о том, что новая версия пакета сломана. Сейчас решения два:
- исправить
- откатить

Второй вариант на данный момент выглядит более правильным (по ряду 
причин, не буду тут их все раскрывать).

> 
> 
> 1. Нужно очертить область примения полиси. Она должна быть возможно более узкой.

Это невозможно. Невозможно отделить узкую область в широкой среде - 
каждый всплеск будет задевать достаточно широкую массу пакетов, что бы 
приводить к коллизиям.

> 2. Нужно определить, за какое время мейнтенер сообщает о планруемых
> серьезных изменениях.

Один месяц - это максимум, который необходим. Но нужно понять, для каких 
случаев имеет смысл сообщать об изменениях, для каких -нет.

> 3. День-два дается на получение заявок от заинтересованных в дискуссии
> мейтейнеров.

Получении заявок ? Может быть сразу начинать дискуссию ?

> 4. Сколько-то дней они пытаются придти к консенсусу.
> 5. Если не приходят, то сообщают об этом в devel@ с изложением точек
> зрения, после чего каждая из сторон спора может пригласить к участию в
> дискуссии какого-либо члена тим.
> 6. Если не приходят к консенсусу и после этого, то выбирают
> консенсусом трех арбитров, которые решают вопрос большинством голосов.
> 7. Если не могут выбрать арбитров то <...> Не хочется до большинства
> голосов доводить, но пока ничего другого не вижу. Ну, или мы все
> выбираем Верховного Арбитра.
> 
> Очень сложно, может быть вы придумаете лучше.

Невыполнимо сложно. На мой взгляд, надо делать проще -
обновления библиотек - по согласованию или NMU на затрагивающиее пакеты.

Обновления типа squashfsprogs - по факту. Предупреждаются за месяц 
(git-commit является предупреждением), после этого идёт обновление - кто 
не успел с ядрами, те подтягиваются. Если кому-то очень сильно мешает, 
то всегда можно откатить по договорённости.

Вот, сегодня тихо и без шума пришёл новый autoconf, который известно - 
ломает сборку ряда пакетов.


На днях - в Sisyphus упал новый gfxboot, который ломает сборку всех 
дизайнов для загрузчиков.

И в первом и во втором случае понятно, что проблемы с новыми пакетами 
будут, понятна необходимость их обновления, так же понятно, что мы в 
любом случае будем делать эти исправления.

Пошумим ? ;)