[devel] Community release^W^WDistro open project: пояснение

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

On Fri, Jun 12, 2009 at 11:16:26PM +0400, George V. Kouryachy wrote:

GVK> Наивно думать, что объявив "дистрибутив, полностью независимый от
GVK> каких-либо ООО" мы _автоматически_ избавимся от конфликта интересов при
GVK> выпуске. Наоборот. Автоматически мы поимеем конфликт чуть ли не каждого
GVK> с каждым. Надеяться на всемогущество полиси тоже нечего, мы не Дебиан.

Кстати и Дебиану тот полиси тоже не слишком-то помогают.

И давайте наконец разделим обсуждения _дистрибутивов_ и _бранчей_?

То что ООО делает какие-то там дистрибутивы -- это касается только ООО и
его заказчиков. Благо есть инфраструктура которая позволяет каждому
выпустить свой дистрибутив имени самого себя и быть счастливым по этому
поводу. Причем так как сейчас, как я понимаю, ООО даже публикует профили
своих дистрибутивов -- то никто не мешает если что-то ему лично в этих
дистрибутивах не нравится -- сделать самому. А потом предложить патч. Вон
сколько чудесных форков Server 4.0 было -- я лично пользуюсь Server'ом от
mike@ :)

Другое дело бранчи -- они являются основой как для дистрибутивов ООО, так
и для дистрибутивов сторонних разработчиков. И нынешняя ситуация когда
сотрудники ООО вносят изменения в бранч игнорируя ACL и не считаясь с
интересами сторонних разработчиков делает бранчи _ненадежной_ основой для
собственных выпусков, что идет в разрез с озвучиваемой политикой ООО
"ребята давайте делать каждый свой дистрибутив если хотите".

GVK> На мой взгляд, шанс community distro принести пользу сообществу -- это
GVK> встроить этот distro в ЖЦ Сизифа. То есть не пытаться вдумать в него
GVK> ничего сверх того, что он есть четвёртая стадия процесса devel - freeze
GVK> - release, сделанная для подтверждения и улучшения надёжности /
GVK> юзабилити соответствующего бранча. Шнас есть, потому что единственное,
GVK> что нас объединяет _по определению_ -- это хранилище, которое мы
GVK> используем. И, значит, есть вероятность, что договоримся.

Если честно, я сторонник того чтобы отправить этот жизненный цикл для
_сизифа_ -- фтопку. Предпочитая иметь этот жизненный цикл отдельно для
каждой из подсистем, а сизиф сделать пригодным для работы здесь и сейчас.

Сизиф это "недостаточно протестированное", но никак не должно быть
"заведомо не рабочее". То есть "мне грабли не известны, но голову на
отсечение что все Ok -- не дам", а не "я тут что-то собрал, запускать
лень, но раз собралось -- выкладываю, и плевать мне на то что это полрепо
развалит".

>>   так и ООО от наличия уже как-то работающего reference-дистрибутива,
>>   на котором дёшевле строить специализированные.
GVK> А вот это нас возвращает к идее трёх эшелонов (Сизиф - Бранч -
GVK> Платформа), а не двух, как предлагал Антон. С одной стороны, идея
GVK> хорошая, так как разруливает конфликт интересов ООО и сообщества по
GVK> наполнению бранча, т. к. всё, что дистрибутивостроитель захочет
GVK> затолкать в дистрибутив насильно (например, ужасно, с точки зрения
GVK> майнтейнера пересобранные пакеты), он будет заталкивать в Платформу
GVK> искюлчительно под свою ответственность.

Да, именно так.

GVK> Здесь главный вопрос: а правда, что на основании "уже как-то работающего
GVK> reference-дистрибутива" _дешевле_ строить специализированные? Но это
GVK> другая тема...

Смотря для какой цели специализированый. Например то что делал я -- это
был по сути Server 4.0.1 со слегка измененной пакетной базой.

Сейчас вижу интересную бизнес идею -- при настройке решения для клиента
давать ему CD, с которого заново будет развернута его система. Но не на
уровне "развернуть cpio", а положив на CD используемые им пакеты а также
конфиги. Клиенты такое хотят и готовы за это платить.

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

http://freesource.info
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20090614/04f23f5e/attachment.bin>