[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