Explain branching policy

Надо формализовать политику ведения веток в форке:

• Какие ветки зеркалят апстрим (master, 2.10 итд)
• Какие ветки чисто наши (суффикс -picodata)
• Как мейнтейнится патчсет (ребейзится)
• Какие версии подлежат выкладке и как тегаются.

Документ предлагаю содержать в одном из коммитов нашего патчсета, например в файле BRANCHING.md.

mentioned in issue picodata/picodata/picodata#200

Основные ветки (из которых мы билдим наши пакеты) именуются по принципу <upstream-tag>-picodata У нас есть некоторый патч-сет, который мы переносим на новый тег при необходимости.

Пример - была ветка 2.10.3-picodata - это 2.10.3 из апстрима, поверх которого ребейзнут наш патчсет (включая CI).
При необходимости мигрировать на 2.10.4 из апстрима, я просто делаю ребейз текущей актуальной ветки (+ черрипикаю мастер при необходимости) на 2.10.4.
Новая ветка становится 2.10.4-picodata

В нашем форке веток, которые зеркалят апстрим нет (вернее, они, возможно, были залиты при собственно форке, но они не поддерживаются в актуальном состоянии). При необходимости - git checkout <upstream>/<branch>
Выкладке подлежит каждый коммит, который попадает в дефолтную ветку гитлаба (дефолтной нужно поддерживать актуальную <tag>-picodata) - это в настройках репы в гитлабе прокликивается.

Из-за некоторой специфики сборки, собранные пакеты будут иметь версию с постфиксом dev. Например, 2.10.4-8.dev. Чтобы этого избежать нужно залить к нам в репу тег с конкретной версией (в примере - 2.10.4-8)

В нашем форке веток, которые зеркалят апстрим нет

А мы не хотим завести? При помощи кроновой джобы в gitlab-ci это не сложно.

а зачем?

Чтобы не делать это ручками, и чтобы мейнтейнерам не надо было настраивать два ремоут урла в гите

После обсуждения в тележке решили, что мы просто пока не доросли

telegram by @gmoshkin:

сейчас picodata-support ветка это

• апстрим 2.11.0-rc2
• патчи с 2.10.5-picodata (которые там были в какой-то момент времени)
• патчи нужные для пикодаты

про патчи с -picodata ветки я мало что знаю, но предполагаю, что в продукте они нам тоже нужны, поэтому видимо их стоит добавлять и туда (-picodata) и туда (picodata-support). возможно так же нам стоит начать вести списки изменений, которые мы добавляем, чтобы ничего не терять при ребейзах

ну а так как picodata-support теперь растёт из 2.11, видимо при ребейзе *-picodata ветки её трогать не надо

@gmoshkin Напиши пожалуйста в https://yt.picodata.io/articles/INT_PICODATA-A-6/Fork-Tarantool

assigned to @gmoshkin

@gmoshkin тебе амнистия. Мы с Димой обновили https://yt.picodata.io/articles/INT_PICODATA-A-6/Fork-Tarantool. Тикет закрываем.

closed

unassigned @gmoshkin

mentioned in merge request !223 (merged)