[devel] Fwd: J23: марш-бросок

[devel] Fwd: J23: марш-бросок

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 3520 bytes --]

	Здравствуйте.
По вроде как согласию остальных участников перевожу сюда.

----- Forwarded message from Michael Shigorin <mike@osdn.org.ua> -----

> ----- Forwarded message from Alexey Tourbin <at@altlinux.ru> -----

<skip>

> пакетов с большими бинарями с оптимизацией -Os и пересборка
> больших пакетов с rpm bzip2 payload compression.

-Os, наверное, осмысленно попробовать, а bzip2 и так уже (давно).

> Тогда базовые средства разработки хорошо войдут.

Они ушли не случайно.  В J1.x их держали для сборки NVIDIA.
И это правильно.

> Сверхзадача, как я её себе представляю, -- отказаться от
> выпуска второго диска вообще. 

Так уже.  Т.е. он _не_ выпускается, но доступен для скачивания.
Другое дело, что IMCO бинарная совместимость с "большим"
дистрибутивом и примерно такой подход к релизам:

   осень'03           осень'03
  /                  /
M3.0--[bugfixes]-->J3.0
 :
 :
[sisyphus]
 :
 :
J3.1--весна'04
 :   /
 :  /
M3.2--[bugfixes]-->J3.2
 :
 :
[sisyphus]
 :
 :
 V

Я сейчас "потерял картинку", но ее компоненты:

время года:
  * видимо, все же весной хорошо бы иметь стабильный выпуск --
    потому как летом никто особенно гарантированно тестингом
    не занимается, как показывают наблюдения, а выкатывать к
    бизнес-периоду -- плохо, к этому моменту переезд на новую
    версию в продакшене уже должен быть завершен и обкатан;
  * а вот осенью можно попробовать выдавать "легкий"
    junior-on-sisyphus (из "мини-фриза", не из базового M -- и
    без поддержки Мастером, в лучшем случае CD2->FTP)
    (мотивация: под бизнес-сезон хорошо бы "засветиться", при
    этом bells'n'whistles играют бОльшую роль, чем средства
    разработки -- при этом для готовящегося M получается
    тестирование)
== это если прицеливаться к текущему темпу выпусков (тж. см.
== историю про релиз-менеджмент mozilla, где "устаканивание
== естественного темпа" было довольно долгим, но произошло)

версионные ассоциации (т.к. некоторые de facto существуют и было
бы осмысленно извлечь из этого толк):

".0"
- M3.0 -- отработка новой технологии (видимо,
  glibc2.3+NPTL+rconf);
- J3.0 -- дежурный OEM-выпуск (который нужен);

".$odd"
- J3.1 -- если sisyphus "уехал", но минифризуем (иначе делается
  как bugfixed J3.0)

".$even"

- M3.2 -- _стабильный_ весенний (см. выше + "по традиции") выпуск;
- J3.2 -- дежурный OEM на его основе.  Возможно, наоборот -- в
  процессе заморозки Sisyphus по дороге к ALM3.2 делается
  "контрольное взвешивание" замороженной части core+master+junior
  (возможно, подмножества).

Кстати, на время заморозки Sisyphus можно частично мигрировать с
разработкой в Daedalus, но тут два момента:

- sass не семижильный и волонтер;
- чтобы не таскать туда-сюда семантику Sisyphus (unstable):
  сегодня с девелопментом туда, завтра сюда, а послезавтра опять
  туда...

...IMO лучше форкать testing/beta (дерево).

Пусть при этом core team снизит активность по sisyphus -- хоть
до нуля -- контрибуторам будет куда забрасывать свою работу, не
дестабилизируя готовящийся релиз.

См. тж. историю linux-2.4.

<skip>

----- End forwarded message -----

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

PPS: пропущенные участки касались сильно разбросанных моментов,
gather по ним _здесь_ чреват неподъемным тредом, посему
<skip>ped.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]