Point branches: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
 
(не показаны 3 промежуточные версии этого же участника)
Строка 16: Строка 16:


== Предлагаемое решение ==
== Предлагаемое решение ==
Предлагаемое решение в значительной степени базируется на [[Binary_package_identity_change]]
Предлагаемое решение в значительной степени базируется на [[Binary_package_identity_change]].
 
Предполагается отказаться от долгоживущих параллельных бранчей в рамках платформы N. Бранчи под сертификацию (или под другие сходные задачи) должны ветвиться от бранча pN. Создание бранчей должно стать куда более рутинной и легковесной операцией.
При этом пользователям предлагается пользоваться не непосредствнно бранчами cN.m, но бранчем cN, который является ссылкой на актуальный бранч cN.m. Ссылка переключается в момент завершения инспекционного контроля или, для других бранчей, в другой аналогичный момент.


[[Файл:point-branches.svg]]
[[Файл:point-branches.svg]]


Предлагаемая схема ветвления может использоваться не только для бранчей под сертификацию, но и для обычных бранчей pN (и tN, если они будут). Представляя из себя систему карманов (если я правильно понимаю -- систему карманов третьего рода), она позволяет подготовить большое изменение, труднореализуемое в рамках одного задания, в бранче pN.n+1, собрать в pN.n+1 задания, которые собрались за это время в pN.n, после чего переключить указатель бранча pN с pN.n на pN.n+1
Исправления по безопасности показаны пунктирными линиями и собираются ± одновременно в несколько бранчей.
 
Предлагаемая схема ветвления может использоваться не только для бранчей под сертификацию, но и для обычных бранчей pN (и tN, если они будут). Представляя из себя систему карманов (если я правильно понимаю -- систему карманов третьего рода), она позволяет подготовить большое изменение, труднореализуемое в рамках одного задания, в бранче pN.m+1, собрать в pN.m+1 задания, которые собрались за это время в pN.m, после чего переключить указатель бранча pN с pN.m на pN.m+1
 
Возможно, следует сделать в girar-builder интерфес для отправки пакета сразу в группу бранчей, хотя тут есть очень даже о чём подумать...


== Применимость для старых бранчей cN ==
== Применимость для старых бранчей cN ==
Для реализации этой схемы желательна реализация [[Binary_package_identity_change]], однако, вовсе не обязательна (то есть её можно внедрить хоть завтра, надо только научиться быстро делать бранчи). Просто у point branches серии cN будет одинаковый суффикс и при этом для них должно быть прописано старшинство, то есть пакеты, собираемые в бранч c7.2 должны иметь большие версии, чем в c7.1. Ну и так ветвление должно осуществляться не от общего бранча pN, а от предыдущего point branch
Для реализации этой схемы желательна реализация [[Binary_package_identity_change]], однако, вовсе не обязательна (то есть её можно внедрить хоть завтра, надо только научиться быстро делать бранчи). Просто у point branches серии cN будет одинаковый суффикс и при этом для них должно быть прописано старшинство, то есть пакеты, собираемые в бранч c7.m+1 должны иметь большие версии, чем в c7.m. Ну и так ветвление должно осуществляться не от общего бранча pN, а от предыдущего point branch


[[Файл:point-branches-legacy.svg]]
[[Файл:point-branches-legacy.svg]]


[[Категория:Branches]]
[[Категория:Branches]]

Текущая версия от 09:10, 1 ноября 2017

Постановка проблемы

Сейчас в рамках платформы существуют бранчи pN и cN, раньше существовал также бранч tN. Эти бранчи должны характеризоваться существенно различным release management, однако, как минимум, обновления по безопасности должны попадать в них во все. Таким образом, мы не можем использовать один бранч для обычных и сертифицированных дистрибутивов, однако полностью раздельная поддержка нескольких бранчей требует много работы и снижает качество результата. Так, для бранчей под сертификацию требуется следующий цикл работы (не реализован сейчас, что доставляет определённые неудобства, которые могут в любой момент стать серьёзными проблемами):

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

И так ad infinitum

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

Предлагаемое решение

Предлагаемое решение в значительной степени базируется на Binary_package_identity_change.

Предполагается отказаться от долгоживущих параллельных бранчей в рамках платформы N. Бранчи под сертификацию (или под другие сходные задачи) должны ветвиться от бранча pN. Создание бранчей должно стать куда более рутинной и легковесной операцией. При этом пользователям предлагается пользоваться не непосредствнно бранчами cN.m, но бранчем cN, который является ссылкой на актуальный бранч cN.m. Ссылка переключается в момент завершения инспекционного контроля или, для других бранчей, в другой аналогичный момент.

Point-branches.svg

Исправления по безопасности показаны пунктирными линиями и собираются ± одновременно в несколько бранчей.

Предлагаемая схема ветвления может использоваться не только для бранчей под сертификацию, но и для обычных бранчей pN (и tN, если они будут). Представляя из себя систему карманов (если я правильно понимаю -- систему карманов третьего рода), она позволяет подготовить большое изменение, труднореализуемое в рамках одного задания, в бранче pN.m+1, собрать в pN.m+1 задания, которые собрались за это время в pN.m, после чего переключить указатель бранча pN с pN.m на pN.m+1

Возможно, следует сделать в girar-builder интерфес для отправки пакета сразу в группу бранчей, хотя тут есть очень даже о чём подумать...

Применимость для старых бранчей cN

Для реализации этой схемы желательна реализация Binary_package_identity_change, однако, вовсе не обязательна (то есть её можно внедрить хоть завтра, надо только научиться быстро делать бранчи). Просто у point branches серии cN будет одинаковый суффикс и при этом для них должно быть прописано старшинство, то есть пакеты, собираемые в бранч c7.m+1 должны иметь большие версии, чем в c7.m. Ну и так ветвление должно осуществляться не от общего бранча pN, а от предыдущего point branch

Point-branches-legacy.svg