November 9th, 2016

404

О цифре 2

Бывает трафик ingress, egress, а бывает 2.
Бывает, что переменная true, false, а бывает, что 2.
Бывает так, что объект либо существует, либо не существует, а бывает, что объект - 2.
Компьютер может быть включен, выключен или 2.
Женщина может быть беременна, не беременна или 2.
Бог либо существует, либо не существует, либо 2.
бинарное значение может содержать либо одно из 2 значений, либо 2.
Монетка падает на орёл или решку, либо 2.
404

gbp & upstream in remote branch

Оно сработало просто идеально - апдейт пакета с 1.0.0 до 1.9.0 произошёл буквально в две минуты.

По размышлению, я понял, что это идеальный метод держать для данного софта:

а) Несколько апстримов - апстрим-апстрим и локальный, с собственными модификациями
б) Несколько веток debian'а, у каждой своя история.

Вся особенность - в указании правильных бранчей в gbp.conf'е, а так как все эти ветки хранятся в одном гите, мы полностью освобождаемся от магических артефактов в форме "tgz из апстрима" и переходим к чистому миру гита.

Даже pq (patch queue) в этой ситуации становится излишним. Если мы что-то хотим пофиксить, мы просто чекаутим апстрим в отдельный бранч, фиксим что нужно, после чего указываем этот бранч как апстрим для нашего "патченного" пакета. Ребейз патчей относительно изменяющегося апстрима решается просто - мы просто cherry-pick'аем изменения по мере надобности. Хотя насчёт правильности этого подхода я не уверен, и, возможно, классическая pq будет лучше. Но в любом случае, саму pq лёгко изготовить из форкнутого бранча, и все изменения хорошо версионированы.

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

Требования простые:

Апстрим в гите
Версии по тегам

Если это есть - git-with-remote-upstream workflow работает на ура.