[devel] Branch6? (branch policy)

[Денис Смирнов]

On Wed, Apr 13, 2011 at 11:50:33AM +0300, Michael Shigorin wrote:

MS> Тут ты не совсем прав -- Master 2.4 выпускался практически
MS> идеально, Server 4.0 тоже очень хорошо, благодаря наличию цели
MS> (дистрибутив), хорошему взаимопониманию _и_ адекватной работе
MS> над релиз-кандидатами.  Но это скорее к release policy,
MS> чем к branch или sisyphus policies.

Это не к полиси, проблема глубже.

Мастер -- это был дистрибутив нужный самой team. Его делали всей толпой
_для себя_. И team, и ООО. И в тот момент я вообще не помню конфликтов
интересов между ООО и team -- первая была просто ядром team. Сейчас же от
этой функции (ядро team) ООО самоустранилось, оставив под своей
ответственностью только инфраструктуру и ряд ключевых компонентов. 

Server 4.0 -- также делался как дистрибутив который нужен и коммьюнити --
тоже. Причем ldv@ пользуется определенным авторитетом, и поэтому его
рекомендации обычно быстро реализовывались.

5.0/p5 это было epic fail. Все дистрибутивы выпущенные ООО на этой базе
были нафиг ненужны никому из community. Напрягаться ради бизнес-интересов
одной компании (даже несмотря на то что успех этой компании важен для
проекта в целом) никто не будет забесплатно. Де-факто 5.1 поддерживался
только потому, что на нем были еще _сторонние_ решения, созданные
community.

Создание mkimage позволило сгладить ситуацию (ООО теперь не делает
дистрибутивов для community, зато community может клепать их себе сколько
угодно по своему желанию), но не исправило ее полностью -- потому что так
и нет reference дистрибутива.

В серверной части его роль де-факто взял на себя server-light. А вот на
десктопе пока все не так гладно. Хотя по технической реализации livecd от
gns@ очень даже претендует на эти лавры :)

Но все это неорганизованно. Множество мелких междусобойчиков. У каждого
свой профиль. Вот я прямо сейчас тоже сижу и хакаю у себя в уголке на
основе профиля от enp@ :)

Множество отдельных решений (в отличии от единого Master 2.4 как
платформы) приводит к необходимости синхронизировать свои действия и
планы. А мы этого -- не умеем.

А еще эксперименты at@ по автоматизации стабилизации Сизифа привели к
тому, что он действительно становится весьма стабильным. В общем-то сейчас
в нем _не_ стабильно разве что то, что софт таки обновляется, и это иногда
ломает обратную совместимость. Глобальных взрывов очень мало (последний
взрыв с потерянными зависимости это хорошо показал -- еще несколько лет
назад это было бы рядовой ситуацией, а не вызвало бы такого ажиотажа).

И для многих бранчи глубокой заморозки -- не нужны, если на них не
обеспечивается полноценный long term support. На который у нас здоровья
таки не хватает (периодически анонсируется LTS, и также периодически он
вырождается в "ежели будет страшный CVE то может быть когда-нибудь пакетик
обновим").

Для этого скорее годится дебиановская схема stable/unstable/testing.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 198 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20110414/898b8b8d/attachment-0001.bin>