[devel] I: 5.0 schedule

[Michael Shigorin]

On Tue, Nov 04, 2008 at 01:36:04AM +0600, Mikhail Gusarov wrote:
>  AN> А вот это _совсем_ другой разговор. Давайте подробнее об этом,
>  AN> пахнет концепцией.
> Видится так: заменить систему бранчей дистрибутивами общего
> назначения (типа Master), разрабатываемыми по правилам
> разработки Сизифа, но с выписанными критериями качества.

Тю, а я думал, ты умный (c)

Бранчи -- это первообразная дистрибутивов.  Тот же Master именно
из бранча и делать всё равно.  Только тут какая проблема: сделать
универсальное намного сложней, чем сделать несколько частных.
Потому что ещё как минимум переключатель.

Т.е. это всё можно, но непринципиально.  Уже обдумано не один год.

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

Она в основном у всех общая.  Причём самый скверный головняк 
(с железом, на которое устанавливаемся) -- едва ли не на 80%,
начиная от vesa для инсталятора.  Разве что у Desktop больное
место -- это wifi, а у Server -- ммм... специфические RAID,
например.

> В частности, это поможет снизить объём дублирующейся работы при
> подготовке RM-ами разных дистрибутивов.

 ет (c)

> Это частично и так происходит, при обновлении бранчей в
> процессе разработки дистрибутивов, но это лучше сказать явно.

Дублирование работы RM возможно снизить:

- стандартизацией mkimage в качестве инструмента сборки;
- свозом профилей в mkimage-profiles-altlinux и вычисткой мусора;
- продолжением выделения installer-feature-* и улучшения сообща;
- резервированием примерно половины времени RM под непредвиденное
  и работу по улучшению инфраструктуры;
- общением по текущим проблемам, а не каждый в своём углу пилит
  и только изредка случайно узнаёт, что рядом победили то же
  самое.

On Tue, Nov 04, 2008 at 03:27:50AM +0600, Mikhail Gusarov wrote:
>  AN> Вы предлагаете схему Debian, которая имеет ряд преимуществ.
> Я предлагаю схему, которая
> * не имеет вечносырого компонента под названием "бранч"

Давай выкинем вечносырой Debian testing и будем делать
хороший всем дистрибутив? :)

Если же серьёзно -- благодаря отсутствию ACL на бранчи, как это
ни парадоксально, как раз и получается их исправлять и улучшать 
уже после выпуска "алюминиевых" дистрибутивов и когда все скорее
забыли и ушли на сизиф.

Вот здесь стоит поискать и выровнять, IMO.

> * укорачивает цепочку от майнтайнера до дистрибутива с непомерной длины
>   в 4 шага (один из которых сейчас обязательно проходит через
>   коммерческую фирму, ту или другую) до одного шага.

Почему непомерной-то?  И с какого перепугу "обязательно"?
Да нет тут проблемы.

> Я не понял, *почему* мой подход не является концептуально продуманным

Ну он и фактологически хромает, бранчи -- это как раз достижение,
а не проблема.  До ALM2.4 включительно под дистрибутив морозился
весь сизиф, а это больно.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/