[devel] Gear и внешние VCS.

[Igor Vlasenko]

Господа,

переношу вопросы автоматизации работы с gear репозиториями,
которые обновляются из удаленнного VCS, в отдельную тему.

Здесь хотел бы обсудить, какие утилиты должны быть добавлены
извне к gear и какие изменения должны быть в самом gear сделаны,
чтобы сделать совместную работу с gear репозиториями,
которые обновляются из удаленнного VCS, 
1) удобной для стороннего человека
2) удобной для робота.

Постараюсь на примерах обрисовать проблему и то,
как должно выглядеть ее решение.

Итак, представим себя в роли члена qa на . Все майнтайнеры на море,
а в это время как раз обнаружена страшная увязвимость headbleed.
Апстримы оперативно выпустили исправления,
майнтайнеров нет, и нужно вместо них обновить их пакеты,
абсолютно чужие, т.е. их gear репозиторий будем видеть в
первый раз.

Что должно быть:
клонируем с git.alt: последнюю собранную версию.

запускаем волшебную команду gear-fetch.
волшебная команда gear-fetch (в gear)
* выкачивает обновление через git (и в идеале, может и git-svn)

над ней может быть моя волшебная надстройка (сакжем,
gear-vcs-update), которая
* (опционально) расставляет при необходимости теги в формате,
который вписан в .gear/rules (например, v на version@).
* (опционально) мержит обновления в ветки с патчами и в master,
вносит изменения в spec.

qa-инженеру остатется только просмотреть изменения и отправить пакет в Сизиф.

но и без волшебной надстройки после gear-fetch все тривиально:
руками мержим, руками add_changelog и послали в Сизиф.

Таперь приземлимся и посмотрим, на что, что есть.

клонируем репозиторий с git.alt и пытаемся руками проэмулировать
волшебную команду gear-fetch, поскольку она еще не существует.

и здесь нас ждет ряд засад. забудем о git-svn, то сплошной ужас.
для простоты пусть будет git. хотим сделать git fetch.

Засада1.  А откуда?

Эта информация есть локально у майнтайнера, но у нас она утеряна --
в нашем клоне репозитория информации о его remotes нет.
Майнтайнер в отпуске на море, слишком далеко, чтобы использовать телепатию.

Пока роемся по сайтам, приходим к выводу, что в репозитории
нужна запись, откуда делать git fetch.

И эта запись должна быть понятной для утилит.
к примеру, запись в спеке
# VCS: ...
может помочь для репозитория Андрея, а в остальных 9 из 10 случаев
означает только, что пакет был основан на Fedor'овском пакете. 
Возможно, роботом дернут, возможно, руками взят.

Т.е. нужен файл в недрах .gear,
.gear/upstream/откуда.

далее, * Засада2 *.

Узнали <Где>, можем написать git getch <Где>. 
но что брать?
git getch <Где> <что>.

Есть commit с исправлениями. и в master, и cherry-pick'ed в ветвях.
Пока думаем и гадаем, приходим к выводу, что нужна запись в недрах .gear,
.gear/upstream[что].

Альтернативно, можно подождать месяц, когда будет <релиз>, а с ним <тег>,
на который можно будет ориентироваться вместо удаленного бранча.

И тут же плавно проваливаемся в *Засаду 3*.

* Засада3 *. куда? 

напомню, полная команда имеет вид 
git fetch <Где> <что>:<куда>

> IV>> поэтому желательно иметь указание, в какие ветви что куда должно идти.
> AF> честно говоря не понял, зачем это ? вижу всё так-же как и в случае с
> тарболлом и исходниками в отдельном бранче. Ну совсем никакой разницы
> -просто вместо gear update будет git pull. остальные этапы точно такие-же.

Для некоторых репозиториев действительно прокатит,
назвать ее как-то устрашающе gearobersturmbannbranch
и сделать fetch в branch gearobersturmbannbranch:

git fetch <Где> <что>:gearobersturmbannbranch

но, во первых, не все .gear/rules основаны на tags,
к примеру, в virt-viewer
$ cat virt-viewer.git/.gear/rules
tar: upstream:.
и волшебная команда gear-fetch должна поддерживать
и такие rules.

Во вторых, для NMU с одноразовым репозиторием это еще 
прокатит, сделали NMU, а репозиторий выбросили.

Но волшебная команда gear-fetch должна быть
в первую очередь удобна для основного майнтайнера.
У него и так есть волшебная команда git fetch origin,
основанная на тайном знании remotes.
Если там записано, что fetch делается в ветку upstream,
то он делается в ветку upstream.

Приходим к выводу, что нужна запись в недрах .gear,
.gear/upstream[куда].

С ней волшебная команда gear-fetch отработает точно так, как 
git fetch origin.

Иначе она просто намусорит: за ней придется прибрать руками,
ветку upstream передвинуть руками, мусор gearobersturmbannbranch
удалить.

далее, ветка(ветки), записанные в .gear/upstream[куда],
должн(ы) отражаться и в .gear/tags.
т.е. gear-update-tag должна поддерживать .gear/upstream[куда],
т.е. записывать в .gear/tags/list текущие позиции этих 
ветвей, чтобы их можно было восстановить, просто
склонировав репозиторий с git.alt и запустив
волшебную команду gear-fetch.

Так я представляю функциональность базовой
волшебной команды gear-fetch.

Функциональность волшебных надстроек над gear-fetch
можно будет обсудить позже, обсуждение лучше начать
с базовых вещей.

-- 

I V