Branches/3.1

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

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

О выпуске

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

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

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

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

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

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

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

Стадия Sync

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

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

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

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

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

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

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

Что сделано

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

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

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