DistroReleasePolicy

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

Общие понятия и определения

• Пакет — программное обеспечение (как в виде исходного кода, так и готовые бинарные сборки), упакованное соответствующим образом для пересборки и установки. Пакет может обладать зависимостями от других пакетов.
• Мейнтейнер — ответственный за сборку и качество пакета.
• Репозиторий — хранилище пакетов, обладающее замыканием по сборке, то есть для каждого пакета существуют все необходимые зависимости для его сборки и установки.
• Sisyphus — нестабильный репозиторий, который развивается постоянно,то есть не обладает ограничениями на размещение в него пакетов.
• Бранч — отдельный репозиторий, существующий фиксированное время (с момента создания до окончания поддержки).
• Бранч для разработки — бранч, на основе которого создается стабилизированный бранч.
• Стабилизированный бранч — бранч, на сонове которого выпускается дистрибутив.
• Генеральный конструктор — лицо, обладающее полномочиями по созданию и стабилизацию бранча. Он принимает решение о сроках и осуществляет создание нового бранча и стабилизацию (замораживание) бранча.
• Дистрибутив — операционная система, состоящая из фиксированного набора пакетов с возможностью установки или использования в режиме LiveCD.
• Релиз-менеджер — лицо, ответственное за создание дистрибутива на базе бранча.
• Менеджер по качеству — лицо, ответственное за качество дистрибутива.

Проблемы

Невозможно создавать дистрибутивы со стабильной пакетной базой при постоянном и неконтролируемом изменении Sisyphus и бранча. Практически невозможно поддерживать такие дистрибутивы.

Цель

Получение прогнозируемой по функциональности, стабильности и качеству пакетной базы для создания дистрибутивов, позволяющей осуществлять долговременную поддержку.

Предложения

Предлагается осуществлять следующую политику сопровождения бранча и создания дистрибутивов в ALT Linux:

1. Бранч для разработки «development branch» создаётся путём копирования Sisyphus в определённое время (в сентябре и марте), полгода идёт к стабилизации. После этого на его основе делается стабилизированный бранч(и) и выпускается дистрибутив(ы). Параллельно создаётся новый бранч для разработки.
2. Стабилизированный бранч «release branch» создаётся путём копирования бранча для разработки с целью выпуска дистрибутива.
3. Этапы развития бранча для разработки и стабилизированного бранча:
   • генеральный конструктор уведомляет мейнтейнеров не позднее чем за две недели о дате создания нового бранча для разработки. При этом мейнтейнеры обеспечивают стабильность своих пакетов в Sisyphus.
   • Происходит создание бранча для разработки путём копирования в определённый заранее день Sisyphus. При этом бранчу присваивается номер версии и для него делается Incoming.
   • В то же время создаётся отдельный пустой репозиторий без жёсткого контроля зависимостей — backports, в который вносятся любые нестабильные изменения.
   • После этого релиз-менеджеры вместе с менеджером по качеству осуществляют:
     • создание и тестирование образов дистрибутивов на базе бранча для разработки (не реже раза в две недели);
     • совместно пишут техническое задание на каждый дистрибутив;
     • работают с мейнтейнерами по исправлению пакетов, чтобы обеспечить заданную функциональность, стабильность и качество;
     • периодически уведомляют в публичных рассылках о сделанных изменениях.
   • В это самое время мейнтернеры могут самостоятельно размещать в бранч для разработки свои новые и исправленные пакеты, также не забывая размещать их и в Sisyphus.
   • За месяц до планируемой даты стабилизации бранча, определяемой генеральным конструктором, происходит следующее:
     • подготавливаются релиз-кандидаты дистрибутивов;
     • пакеты из Incoming перекладываются в бранч для разработки только после проверки менеджером по качеству;
     • готовится окончательный вариант технического задания;
     • готовится список изменений.
   • В заданную дату бранч стабилизируется. Стабилизация подразумевает запрет на внесение любых изменений, кроме исправлений по безопасности и исправления критичных ошибок, которые размещаются в стабильный бранч.
   • Происходит создание стабилизированного бранча путём копирования в определённый заранее день бранча для разработки. При этом стабилизированному бранчу присваивается номер релиза (Например, для бранча 5.0 — релиз 5.0.4). Incoming для него не делается?.
   • После этого в cтабилизированный бранч вносятся только изменения по безопасности и исправления критичных ошибок.
   • на базе стабилизированного бранча выпускаются (сразу или позже) дистрибутивы с мажорной версией, соответствующей версии бранча для разработки и его собственным релизом.
   • Стабилизированный бранч служит источником официальных обновлений к релизу.
   • После выпуска стабилизированного бранча бранч для разработки размораживается, некритичные исправления и новые версии пакетов (кроме новых версий toolchains и совместно используемых библиотек) продолжают выкладываться в бранч для разработки по желанию членов community.
   • бранч для разработки служит источником неофициальных обновлений к релизу.
   • нестабильные изменения, в том числе новые версии библиотек и toolchains, выкладываются в backports.
   • Генеральный конструктор может по желанию либо повторять процедуру стабилизации к бранчу для разработки, либо перекладывать в стабилизированный бранч отдельные пакеты.

Периодичность выпуска дистрибутивов

• Десктопные дистрибутивы — раз в полгода.
• Серверные дистрибутивы — раз в год.