[devel] Концепция политики разработки дистрибутивов ALT Linux

Igor Vlasenko =?iso-8859-1?q?vlasenko_=CE=C1_imath=2Ekiev=2Eua?=
Пт Авг 1 12:24:44 MSD 2008


On Fri, Aug 01, 2008 at 11:54:54AM +0400, Aleksey Avdeev wrote:
>   При возможности ничего не ломающего обновления -- допускать.
+1.

Обобщая, предлагаю схему Миши Шигорина==debian, но в наших
реалиях, как оно по сути и есть, только его нужно 
расставить по полочкам.

И так, дистрибутив X.Y:
к нему 3 репозитария:

1)
updates/X.Y - это то, что хочет уважаемый Андрей Черепанов <cas@>.
После стабилизации для бранча выпускаются только обновления по безопасности.

2)
branch/X.Y - это то, что хочет народ:
> Т.е. собственно вопрос: допускать ли обновление версии в бранче, если на то
> есть веские причины типа серьёзных исправлений?
При возможности ничего не ломающего обновления -- допускать.

3)
backports/X.Y - место для потенциально ломающих обюновлений.
При этом у меня есть RFC для следующего дополнения к backports полиси:

============== RFC ==================
Пакеты в backports в силу своей потенциальной нестабильности 
должны быть атомарно изолированы. 

Т.е. при попадании в incoming backports пакет должен сначала
собираться в окружении distro+branch, и только если попытка
сборки не удалась, то в  окружении distro+branch+backports.

В спорных ситуациях бакпортер всегда явно может затребовать
пакет из backports, явно указав foo >= ver.
=====================================

Обоснование: чтобы при обновлении из backports один нестабильный
пакет не тянул заведомо для него лишние другие нестабильные пакеты.


Осталось только принять такое полиси и явно развести инкоминги
для бранчей и updates (backports уже есть), чтобы легко было видно,
куда эта сборка позиционируется.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine




Подробная информация о списке рассылки Devel