[devel] С наступающим новым бранчем

[Vitaly Kuznetsov]

Alexey Tourbin <at �� altlinux.ru> writes:

> Мое предложение: создать community branch 5.1 как основной.
> И создать extra-stable OOO бранч 5.1-OOO (опаздывающий) как
> производный
> от 5.1.  А именно, если не обнаруживается проблем с бранчем 5.1, то он
> вливается (на регулярной основе) в бранч 5.1-OOO.  Уточнение: проблемы
> трафика проблемой не считаются.
>
> Если же в 5.1 обнаруживается привнесенная нестабильность,
> то есть варианты действий.  Но, в конечном счете, как цель,
> надо декларировать синхронизацию 5.1 и 5.1-OOO.


Попытаюсь объяснить чем такая схема (sisyphus -> c5 -> p5) не устраивает.

К примеру, в с5 приехал пакетик A с новой версией. С ним пересобрались
обновления пакетиков B и С. Наш QA знает, что согласно обязательствам мы
не можем пустить в p5 новую версию пакетика А. Причины прописаны в
договорах и абсолютно неинтересны community.
Вопрос - что делать дальше? Обновления пакетиков B и C нам нужны. 
Наступает момент, с которого мы не можем делать синхронизацию.

Аналогичная ситуация возникает при внесении изменений в p5 в обход с5
(опять же, согласно обязательствам). 

Можно предложить специальный тип заданий для сборочницы, одновременно
собирающий задания и в c5 и, в случае успешной сборки) в p5. После этого
задание в p5 вещается на hold до решения QA.