DistroReleasePolicy: различия между версиями
| Строка 23: | Строка 23: | ||
=== Предложения === | === Предложения === | ||
Предлагается осуществлять следующую политику сопровождения бранча и создания дистрибутивов в ALT Linux: | Предлагается осуществлять следующую политику сопровождения бранча и создания дистрибутивов в ALT Linux: | ||
# Бранч создаётся путём копирования Sisyphus в определённое время (в сентябре и марте) и существует полгода. После этого создаётся новый бранч. | # Бранч для разработки создаётся путём копирования Sisyphus в определённое время (в сентябре и марте) и существует полгода. После этого создаётся новый бранч. | ||
# Этапы развития бранча: | # Этапы развития бранча для разработки: | ||
#* генеральный конструктор уведомляет мейнтейнеров не позднее чем за две недели о дате создания нового бранча. При этом мейнтейнеры обеспечивают стабильность своих пакетов в Sisyphus. | #* генеральный конструктор уведомляет мейнтейнеров не позднее чем за две недели о дате создания нового бранча. При этом мейнтейнеры обеспечивают стабильность своих пакетов в Sisyphus. | ||
#* Происходит создание бранча путём копирования в определённый заранее день Sisyphus. При этом бранчу присваивается номер версии и для него делается [[Incoming]]. | #* Происходит создание бранча для разработки путём копирования в определённый заранее день Sisyphus. При этом бранчу присваивается номер версии и для него делается [[Incoming]]. | ||
#* В то же время создаётся отдельный пустой репозиторий без жёсткого контроля зависимостей — backports, в который вносятся любые нестабильные изменения. | |||
#* После этого релиз-менеджеры вместе с менеджером по качеству осуществляют: | #* После этого релиз-менеджеры вместе с менеджером по качеству осуществляют: | ||
#** создание и тестирование образов дистрибутивов на базе бранча (не реже раза в две недели). | #** создание и тестирование образов дистрибутивов на базе бранча для разработки (не реже раза в две недели). | ||
#** совместно пишут техническое задание на каждый дистрибутив. | #** совместно пишут техническое задание на каждый дистрибутив. | ||
#** работают с мейнтейнерами по исправлению пакетов, чтобы обеспечить заданную функциональность, стабильность и качество. | #** работают с мейнтейнерами по исправлению пакетов, чтобы обеспечить заданную функциональность, стабильность и качество. | ||
#** периодически уведомляют в публичных рассылках о сделанных изменениях. | #** периодически уведомляют в публичных рассылках о сделанных изменениях. | ||
#* В это самое время мейнтернеры могут самостоятельно размещать в бранч свои новые и исправленные пакеты, также не забывая размещать их и в Sisyphus. | #* В это самое время мейнтернеры могут самостоятельно размещать в бранч для разработки свои новые и исправленные пакеты, также не забывая размещать их и в Sisyphus. | ||
#* За месяц до планируемой даты стабилизации бранча, определяемой генеральным конструктором происходит следующее: | #* За месяц до планируемой даты стабилизации бранча, определяемой генеральным конструктором происходит следующее: | ||
#** подготавливаются релиз-кандидаты дистрибутивов. | #** подготавливаются релиз-кандидаты дистрибутивов. | ||
#** пакеты из Incoming перекладываются в бранч только после проверки менеджером по качеству. | #** пакеты из Incoming перекладываются в бранч для разработки только после проверки менеджером по качеству. | ||
#** готовится окончательный вариант технического задания. | #** готовится окончательный вариант технического задания. | ||
#** готовится список изменений. | #** готовится список изменений. | ||
#* В заданную дату бранч стабилизируется и на его базе выпускаются (сразу или позже) дистрибутивы с мажорной версией, соответствующей версии бранча. Стабилизация подразумевает запрет на внесение любых изменений, кроме исправлений по безопасности и исправления критичных ошибок, которые размещаются в бранч. | #* В заданную дату бранч стабилизируется и на его базе выпускаются (сразу или позже) дистрибутивы с мажорной версией, соответствующей версии бранча. Стабилизация подразумевает запрет на внесение любых изменений, кроме исправлений по безопасности и исправления критичных ошибок, которые размещаются в стабильный бранч. | ||
#* После этого в бранч вносятся только изменения по безопасности и исправления критичных ошибок. | #* Происходит создание стабилизированного бранча путём копирования в определённый заранее день простого бранча. При этом бранчу присваивается номер релиза (Например, для бранча 5.0 - релиз 5.0.4). [[Incoming]] для него не делается?. | ||
#* Стабилизированный бранч служит источником обновлений | #* После этого в cтабилизированный бранч вносятся только изменения по безопасности и исправления критичных ошибок. | ||
#* | #* Стабилизированный бранч служит источником официальных обновлений к релизу. | ||
#* После выпуска стабилизированного бранча бранч для разработки размораживается, некритичные исправления и новые версии пакетов продолжают выкладываться в бранч для разработки. | |||
=== Периодичность выпуска дистрибутивов === | === Периодичность выпуска дистрибутивов === | ||
Версия от 13:58, 21 августа 2008
Концепция политики разработки дистрибутивов ALT Linux
Общие понятия и определения
- Пакет — программное обеспечение (как в виде исходного кода, так и готовые бинарные сборки), упакованное соответствующим образом для пересборки и установки. Пакет может обладать зависимостями от других пакетов.
- Мейнтейнер — ответственный за сборку и качество пакета.
Репозиторий — хранилище пакетов, обладающее замыканием по сборке, то есть для каждого пакета существуют все необходимые зависимости для его сборки и установки.
- Sisyphus — нестабильный репозиторий, который развивается постоянно,то есть не обладает ограничениями на размещение в него пакетов.
- Бранч — отдельный репозиторий, существующий фиксированное время (с момента создания до стабилизации).
- Генеральный конструктор — лицо, обладающее полномочиями по созданию и стабилизацию бранча. Он принимает решение о сроках и осуществляет создание нового бранча и стабилизацию (замораживание) бранча.
- Дистрибутив — операционная система, состоящая из фиксированного набора пакетов с возможностью установки или использования в режиме LiveCD.
- Релиз-менеджер — лицо, ответственное за создание дистрибутива на базе бранча.
- Менеджер по качеству — лицо, ответственное за качество дистрибутива.
Проблемы
Невозможно создавать дистрибутивы со стабильной пакетной базой при постоянном и неконтролируемом изменении Sisyphus и бранча. Практически невозможно поддерживать такие дистрибутивы.
Цель
Получение прогнозируемой по функциональности, стабильности и качеству пакетной базы для создания дистрибутивов, позволяющей осуществлять долговременную поддержку.
Предложения
Предлагается осуществлять следующую политику сопровождения бранча и создания дистрибутивов в ALT Linux:
- Бранч для разработки создаётся путём копирования Sisyphus в определённое время (в сентябре и марте) и существует полгода. После этого создаётся новый бранч.
- Этапы развития бранча для разработки:
- генеральный конструктор уведомляет мейнтейнеров не позднее чем за две недели о дате создания нового бранча. При этом мейнтейнеры обеспечивают стабильность своих пакетов в Sisyphus.
- Происходит создание бранча для разработки путём копирования в определённый заранее день Sisyphus. При этом бранчу присваивается номер версии и для него делается Incoming.
- В то же время создаётся отдельный пустой репозиторий без жёсткого контроля зависимостей — backports, в который вносятся любые нестабильные изменения.
- После этого релиз-менеджеры вместе с менеджером по качеству осуществляют:
- создание и тестирование образов дистрибутивов на базе бранча для разработки (не реже раза в две недели).
- совместно пишут техническое задание на каждый дистрибутив.
- работают с мейнтейнерами по исправлению пакетов, чтобы обеспечить заданную функциональность, стабильность и качество.
- периодически уведомляют в публичных рассылках о сделанных изменениях.
- В это самое время мейнтернеры могут самостоятельно размещать в бранч для разработки свои новые и исправленные пакеты, также не забывая размещать их и в Sisyphus.
- За месяц до планируемой даты стабилизации бранча, определяемой генеральным конструктором происходит следующее:
- подготавливаются релиз-кандидаты дистрибутивов.
- пакеты из Incoming перекладываются в бранч для разработки только после проверки менеджером по качеству.
- готовится окончательный вариант технического задания.
- готовится список изменений.
- В заданную дату бранч стабилизируется и на его базе выпускаются (сразу или позже) дистрибутивы с мажорной версией, соответствующей версии бранча. Стабилизация подразумевает запрет на внесение любых изменений, кроме исправлений по безопасности и исправления критичных ошибок, которые размещаются в стабильный бранч.
- Происходит создание стабилизированного бранча путём копирования в определённый заранее день простого бранча. При этом бранчу присваивается номер релиза (Например, для бранча 5.0 - релиз 5.0.4). Incoming для него не делается?.
- После этого в cтабилизированный бранч вносятся только изменения по безопасности и исправления критичных ошибок.
- Стабилизированный бранч служит источником официальных обновлений к релизу.
- После выпуска стабилизированного бранча бранч для разработки размораживается, некритичные исправления и новые версии пакетов продолжают выкладываться в бранч для разработки.
Периодичность выпуска дистрибутивов
Десктопные дистрибутивы — раз в полгода.
Серверные дистрибутивы — раз в год.