Branches/ReleasePolicy
Материал из ALT Linux Wiki
< Branches
[править] Концепция политики разработки дистрибутивов ALT Linux
Содержание[убрать] |
[править] Общие понятия и определения
- Пакет ? программное обеспечение (как в виде исходного кода, так и готовые бинарные сборки), упакованное соответствующим образом для пересборки и установки. Пакет может обладать зависимостями от других пакетов.
- Мейнтейнер ? ответственный за сборку и качество пакета.
Репозиторий ? хранилище пакетов, обладающее замыканием по сборке, то есть для каждого пакета существуют все необходимые зависимости для его сборки и установки.
- Sisyphus ? нестабильный репозиторий, который развивается постоянно,то есть не обладает ограничениями на размещение в него пакетов.
- Бранч ? отдельный репозиторий, существующий фиксированное время (с момента создания до окончания поддержки).
- Бранч для разработки ? бранч, на основе которого создается стабилизированный бранч.
- Стабилизированный бранч ? бранч, на сонове которого выпускается дистрибутив.
- Генеральный конструктор ? лицо, обладающее полномочиями по созданию и стабилизацию бранча. Он принимает решение о сроках и осуществляет создание нового бранча и стабилизацию (замораживание) бранча.
- Дистрибутив ? операционная система, состоящая из фиксированного набора пакетов с возможностью установки или использования в режиме LiveCD.
- Релиз-менеджер ? лицо, ответственное за создание дистрибутива на базе бранча.
- Менеджер по качеству ? лицо, ответственное за качество дистрибутива.
[править] Проблемы
Невозможно создавать дистрибутивы со стабильной пакетной базой при постоянном и неконтролируемом изменении Sisyphus и бранча. Практически невозможно поддерживать такие дистрибутивы.
[править] Цель
Получение прогнозируемой по функциональности, стабильности и качеству пакетной базы для создания дистрибутивов, позволяющей осуществлять долговременную поддержку.
[править] Предложения
Предлагается осуществлять следующую политику сопровождения бранча и создания дистрибутивов в ALT Linux:
- Бранч для разработки "development branch" создается путем копирования Sisyphus в определенное время (в сентябре и марте), полгода идет к стабилизации. После этого на его основе делается стабилизированный бранч(и) и выпускается дистрибутив(ы). Параллельно создается новый бранч для разработки.
- Стабилизированный бранч "release branch" создается путем копирования бранча для разработки с целью выпуска дистрибутива.
- Этапы развития бранча для разработки и стабилизированного бранча:
- генеральный конструктор уведомляет мейнтейнеров не позднее чем за две недели о дате создания нового бранча для разработки. При этом мейнтейнеры обеспечивают стабильность своих пакетов в Sisyphus.
- Происходит создание бранча для разработки путем копирования в определенный заранее день Sisyphus. При этом бранчу присваивается номер версии и для него делается Incoming.
- В то же время создается отдельный пустой репозиторий без жесткого контроля зависимостей ? backports, в который вносятся любые нестабильные изменения.
- После этого релиз-менеджеры вместе с менеджером по качеству осуществляют:
- создание и тестирование образов дистрибутивов на базе бранча для разработки (не реже раза в две недели).
- совместно пишут техническое задание на каждый дистрибутив.
- работают с мейнтейнерами по исправлению пакетов, чтобы обеспечить заданную функциональность, стабильность и качество.
- периодически уведомляют в публичных рассылках о сделанных изменениях.
- В это самое время мейнтернеры могут самостоятельно размещать в бранч для разработки свои новые и исправленные пакеты, также не забывая размещать их и в Sisyphus.
- За месяц до планируемой даты стабилизации бранча, определяемой генеральным конструктором происходит следующее:
- подготавливаются релиз-кандидаты дистрибутивов.
- пакеты из Incoming перекладываются в бранч для разработки только после проверки менеджером по качеству.
- готовится окончательный вариант технического задания.
- готовится список изменений.
- В заданную дату бранч стабилизируется. Стабилизация подразумевает запрет на внесение любых изменений, кроме исправлений по безопасности и исправления критичных ошибок, которые размещаются в стабильный бранч.
- Происходит создание стабилизированного бранча путем копирования в определенный заранее день бранча для разработки. При этом стабилизированному бранчу присваивается номер релиза (Например, для бранча 5.0 - релиз 5.0.4). Incoming для него не делается?.
- После этого в cтабилизированный бранч вносятся только изменения по безопасности и исправления критичных ошибок.
- на базе стабилизированного бранча выпускаются (сразу или позже) дистрибутивы с мажорной версией, соответствующей версии бранча для разработки и его собственным релизом.
- Стабилизированный бранч служит источником официальных обновлений к релизу.
- После выпуска стабилизированного бранча бранч для разработки размораживается, некритичные исправления и новые версии пакетов (кроме новых версий toolchains и совместно используемых библиотек) продолжают выкладываться в бранч для разработки по желанию членов community.
- бранч для разработки служит источником неофициальных обновлений к релизу.
- нестабильные изменения, в том числе новые версии библиотек и toolchains, выкладываются в backports.
- Генеральный конструктор может по желанию либо повторять процедуру стабилизации к бранчу для разработки либо перекладывать в стабилизированный бранч отдельные пакеты.
[править] Периодичность выпуска дистрибутивов
Десктопные дистрибутивы ? раз в полгода.
Серверные дистрибутивы ? раз в год.
