[devel] полиси внесения существенных изменений
Anton Farygin
=?iso-8859-1?q?rider_=CE=C1_altlinux=2Ecom?=
Вт Авг 5 15:28:43 MSD 2008
Всё можно сделать гораздо проще:
мантейнеры пишут вежливые письма, когда их что-то начинает напрягать в
сборках других пакетов.
Находится взаимно-всех-устраивающее решение.
На всё - неделя максимум. Фиксированный срок на обсуждение. Иначе мы так
и будем полоскать друг другу нервы всё время, а процесс будет простаивать.
Я бы добавил ещё пункт, что обсуждаются только коллизии с решениями,
интегрированными в Sisyphus. Например, нет смысла обсуждать
работоспособность ядра Debian на Sisyphus - и так будет понятно, что оно
без изменений работать не станет.
Правда и во всех этих схемах непонятно, как учитывать интересы различных
сторонних проприетарных продуктов.
Aleksey Novodvorsky пишет:
> Коллеги,
> возможно, нам нужно создать полиси, регулирующую принятие решений в
> случаях, аналогичных внесению изменений в sqashfsprogs.
Тогда нам будет необходимо обсуждать необходимость обновления всех
версий всех программ в репозитарии. Это unreal.
Пример из жизни - обновился synaptics. Сломался тачпад. Если бы мы перед
этим обсуждали необходимость его обновления, то думаю, что мы бы никогда
не узнали о том, что новая версия пакета сломана. Сейчас решения два:
- исправить
- откатить
Второй вариант на данный момент выглядит более правильным (по ряду
причин, не буду тут их все раскрывать).
>
>
> 1. Нужно очертить область примения полиси. Она должна быть возможно более узкой.
Это невозможно. Невозможно отделить узкую область в широкой среде -
каждый всплеск будет задевать достаточно широкую массу пакетов, что бы
приводить к коллизиям.
> 2. Нужно определить, за какое время мейнтенер сообщает о планруемых
> серьезных изменениях.
Один месяц - это максимум, который необходим. Но нужно понять, для каких
случаев имеет смысл сообщать об изменениях, для каких -нет.
> 3. День-два дается на получение заявок от заинтересованных в дискуссии
> мейтейнеров.
Получении заявок ? Может быть сразу начинать дискуссию ?
> 4. Сколько-то дней они пытаются придти к консенсусу.
> 5. Если не приходят, то сообщают об этом в devel@ с изложением точек
> зрения, после чего каждая из сторон спора может пригласить к участию в
> дискуссии какого-либо члена тим.
> 6. Если не приходят к консенсусу и после этого, то выбирают
> консенсусом трех арбитров, которые решают вопрос большинством голосов.
> 7. Если не могут выбрать арбитров то <...> Не хочется до большинства
> голосов доводить, но пока ничего другого не вижу. Ну, или мы все
> выбираем Верховного Арбитра.
>
> Очень сложно, может быть вы придумаете лучше.
Невыполнимо сложно. На мой взгляд, надо делать проще -
обновления библиотек - по согласованию или NMU на затрагивающиее пакеты.
Обновления типа squashfsprogs - по факту. Предупреждаются за месяц
(git-commit является предупреждением), после этого идёт обновление - кто
не успел с ядрами, те подтягиваются. Если кому-то очень сильно мешает,
то всегда можно откатить по договорённости.
Вот, сегодня тихо и без шума пришёл новый autoconf, который известно -
ломает сборку ряда пакетов.
На днях - в Sisyphus упал новый gfxboot, который ломает сборку всех
дизайнов для загрузчиков.
И в первом и во втором случае понятно, что проблемы с новыми пакетами
будут, понятна необходимость их обновления, так же понятно, что мы в
любом случае будем делать эти исправления.
Пошумим ? ;)
Подробная информация о списке рассылки Devel