Ветка 3.1 (2006/Осень)

Ветка 3.1 была отменена. К сожалению, никакого postmortem-анализа сделано не было, так что используйте информацию с этой страницы очень осторожно.

О выпуске

Это — наша первая попытка плановой стабилизации и выпуска Сизифа. Никто не может в точности сказать, сколько времени нам потребуется на «игру в догонялки» (Sync), стабилизацию (Freeze) и доводку (Testing). Заложим для начала по месяцу на каждый процесс. Даты, указанные в /Sisyphus Release, будем подправлять по ходу работы. Обратите внимание, что заморозка средств разработки и библиотек должна естественным образом предшествовать заморозке приложений. На сегодняшний день построить жёсткую последовательность невозможно, так что понадеемся на «естественность образа» и сознательность тех, кто сопровождает такие пакеты.

Важные пакеты

Для того, чтобы выпуск не затягивался навечно и тем не менее получился стабильным, необходимо очертить круг пакетов, кторые непременно должны попасть в выпуск без серьёзных ошибок. Для вешания и отслеживания ошибок у нас есть https://bugzilla.altlinux.org:

• Дисциплина оформления ошибок в ALT Linux Bugzilla
• На многих пакетах висят открытые ошибки, которые на самом деле давно закрыты! Это сильно замусоривает журнал незакрытых ошибок.
• На многих пакетах висят FIXED-ошибки. FIXED, но не CLOSED. Это тоже сильно замусоривает журнал незакрытых ошибок.

Но одной Багзиллы мало. На сегодняшний день в Sisyphus имеются героические персоны, сопровождающие по нескольку сотен пакетов (один lav@ чего стоит!). Очевидно, они если и пользуются этими пакетами, то уж точно не в состоянии их все разом протестировать. Значит, помимо сопровождающего (maintainer) появляется ещё и пользователь (tester) пакета.
Господа! Пополняйте Список пакетов и их пользователей!

Важные ошибки

Создан аккумулятор ошибок “ALT Linux 3.1 blocker” bug #9199. Просьба все ошибки и FR, исправление которых должно, по-вашему, предшествовать выпуску Сизифа, ставить в “depends” этой ошибке.

Стадия Sync

В этот раз стадия Sync заняла вместо одного месяца — три. Это на месяц больше запланированного максимального срока. Почему?

1. Ключевые неподдерживаемые пакеты. Пакет всем нужен, но давно сломан, и никто за него не берётся. Очевидно, что за месяц найти того, кто возьмётся, и довести пакет до ума невозможно. Мораль: компоненты, важные для выпуска надо держать в работоспособном состоянии по возможности всегда.
2. Закрытая разработка. Такие ключевые пакеты, как семейство installer, семейство spt, hwdatabase и т. п. разрабатывались одним-тремя людьми без возможности сообществу включиться в разработку (нет документации, нет средств совместной разработки, нет roadmap). Следствие — как только автор от разработки уходит, пакет перестаёт существовать.
3. Субъективные трудности (a.k.a. «правило *3»). Чаще всего наши личные рабочие планы оказываются в три раза дольше, чем мы планируем — по субъективным причинам. Выход один: начинать с самых приоритетных задач и жертвовать неприоритетными, когда срок подожмёт.
4. Объективные трудности. Выпуск XOrg и ядра 2.6.18 пришёлся на конец осени, пришлось подождать и того, и дргугого.

Стадия Freeze

Крупные недоделки

Некоторые части Сизифа, которые обязаны войти в выпуск, находятся в весьма нестабильном или устаревшем состоянии.

• Программа установки (Installer)
• Программа сборки загрузочных образов (семейство SPT)
• Комплекс программ для работы с устройствами (Udev / Hotplug / HAL и т. п.)
• Старый Open SSL, внося который в выпуск мы обречены его поддерживать до следующего «большого» дистрибутива
• Полноценная пакетная база x86_64 (в частности, модули python). Можно заглядывать в список собирающихся на *64 пакетов.

Состояние Сизифа как показатель стабильности

есть ли какая-нибудь одна ссылка, где информация об unmet и несборке обновлялась бы автоматически?

Что сделано

• Установщик во многом переведён на ALTerator. Исходные коды установщика находятся в git.alt. Документирование пока ждёт своего часа:(
  
• Стартовал документированный и модульный проект SPT3 — инструмента сборки загружаемых систем (в т. ч. ISO-образов установщика и Live CD)
• Часть работ в настоящее время выполняется сотрудниками ALT Linux

О самоуправлении

Поскольку очевидно, что подобный процесс (в некоторых кругах именуемый Release Management :) не может организоваться сам собой, поглядывать за ним и вовремя оповещать сообщество берусь я, Георгий Курячий. Я же беру на себя и более сильную ответственность: в случае спорных и/или конфликтных ситуаций (и только в них) последнее слово по этому выпуску — за мной.