DistroReleasePolicy

Материал из ALT Linux Wiki
(перенаправлено с «Branches/ReleasePolicy»)

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

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

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

Проблемы

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

Цель

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

Предложения

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

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

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

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