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

[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

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

[Anton Farygin]

On 18.06.2014 02:59, Igor Vlasenko wrote:
> Засада1.  А откуда?
Это же просто. С репозитория, указанного в watch файле. Если такого нет, 
то два варианта:
1) автоматическое обновление не работает
2) добавить свой watch файл, нагуглив репозиторий апстрима.
> далее, * Засада2 *.
>
> Узнали <Где>, можем написать git getch <Где>.
> но что брать?
> git getch <Где> <что>.
>
> Есть commit с исправлениями. и в master, и cherry-pick'ed в ветвях.
> Пока думаем и гадаем, приходим к выводу, что нужна запись в недрах .gear,
> .gear/upstream[что].
Нет. нужна запись в watch файле - регексп, описывающий тэг на основании 
которого можно сделать вывод о новом релизе.
и брать надо именно тэг - не ветки же тащить с апстрима.

>
> Альтернативно, можно подождать месяц, когда будет <релиз>, а с ним <тег>,
> на который можно будет ориентироваться вместо удаленного бранча.
Эээ... а кто-то хочет собирать не-релизы ? а зачем ?
>
> И тут же плавно проваливаемся в *Засаду 3*.
>
> * Засада3 *. куда?
>
> напомню, полная команда имеет вид
> git fetch <Где> <что>:<куда>
см. ниже. На самом деле, ответ "куда" должен сформироваться из 
.gear/rules - это сильно зависит от того, как устроен обрабатываемый гит.
>
>> 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.
А должна ли ? почему-то rpm-uscan не поддерживает репозитории без watch 
файлов.
>
> Во вторых, для NMU с одноразовым репозиторием это еще
> прокатит, сделали NMU, а репозиторий выбросили.
>
> Но волшебная команда gear-fetch должна быть
> в первую очередь удобна для основного майнтайнера.
> У него и так есть волшебная команда git fetch origin,
> основанная на тайном знании remotes.
> Если там записано, что fetch делается в ветку upstream,
> то он делается в ветку upstream.
>
> Приходим к выводу, что нужна запись в недрах .gear,
> .gear/upstream[куда].
или в watch файле, да.

например:
git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git 
v([0-9]*\.[0-9]*) local:upstream


Кстати, это же "полечит" проблему из virt-viewer, хотя я по прежднему 
думаю что указывать ветку в качестве источника тарболла - криво.
>
> С ней волшебная команда 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
> можно будет обсудить позже, обсуждение лучше начать
> с базовых вещей.
>

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

[Igor Vlasenko]

On Wed, Jun 18, 2014 at 10:07:48AM +0400, Anton Farygin wrote:
> git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
> v([0-9]*\.[0-9]*) local:upstream

да, что-то такое я и думаю сделать в обвязках над.
но, разбить этот файл на 2 части:
aналог watch, скажем release-tag-filter,
в котором будет только

v?([0-9]*\.[0-9]*)

и, скажем, .gear/upstream-remotes,

в котором будет храниться информация, которую в старом формате 
remotes можно было записать как

URL: git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
Pull: master:upstream

а в формате git config --list ее можно записать как
#remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
branch.upstream.remote=origin
branch.upstream.merge=refs/heads/upstream

За день осмыслилось, что и gear-fetch не нужен,
достаточно 2-х более простых утилит,
gear-save-remotes и gear-restore-remotes.

Зачем так важно выделить информацию о remotes в отдельный файл?
чтобы сразу вдобавок к возможности отслеживания решить
и другую, на мой взгляд более важную, задачу:

Дать стандартный способ майнтайнерам поделиться с коллегами,
как же обновлять их репозиторий.

Потому что в текущем виде gear репозитории не дружественны
к совместной работе. tarball-обновляемые gear репозитории
дружественны, src.rpm дружественны, а VCS-обновляемые - нет.

Представьте себе, что ваш обновляемый из апстримного git
репозиторий какой-то добрый человек поверх обновил из
tarball'а и отправил на сборку в Сизиф.

Похожее чувство я испытываю, когда нужно обновить перловую
зависимость, но соответствуюший пакет обновляется из VCS.
Там весь пакет на 200 строчек. Я знаю, какая там версия. 
У меня под рукой свежий апстримный tarball. 
Но я не могу взять и обновить - надо рыться в VCS-помойках
и искать, где этот ****ов git и затем настраивать (каждый раз!)
клонированный репозиторий, и все только для того, 
чтобы сделать git fetch origin.

И майнтайнер, который разместил свой пакет в VCS-обновляемом 
gear репозитории не виноват --- это дыра в дизайне gear,
которая делает VCS-обновляемые gear репозитории гораздо худшим
средством для _совместной_ разработки, чем src.rpm.

И всего-то надо инструмент, чтобы gear репозиторий
хранил в себе свои remotes.

как минимум, что-то вроде
gear-save-remotes и gear-restore-remotes

Это удобно и NMUшникам, и основному майнтайнеру:
если remotes не сохраняются, то на git.alt копии его 
репозиториев неполноценные, и если слетит диск,
то не достаточно будет склонировать их с git.alt,
придется заново тратить время на восстановление 
локальных настроек remotes (а если использовался
git-svn, то там все вообще печально).

Да и на даче / в походе удобнее -
не нужно таскать с собой диски 
или тратить время на настройку git-клона.

-- 

I V

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

[Anton Farygin]

On 19.06.2014 01:28, Igor Vlasenko wrote:
> On Wed, Jun 18, 2014 at 10:07:48AM +0400, Anton Farygin wrote:
>> git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git
>> v([0-9]*\.[0-9]*) local:upstream
>
> да, что-то такое я и думаю сделать в обвязках над.
> но, разбить этот файл на 2 части:
> aналог watch, скажем release-tag-filter,
> в котором будет только
>
> v?([0-9]*\.[0-9]*)
>
> и, скажем, .gear/upstream-remotes,
<skip>
>
> И всего-то надо инструмент, чтобы gear репозиторий
> хранил в себе свои remotes.
>
> как минимум, что-то вроде
> gear-save-remotes и gear-restore-remotes
>
> Это удобно и NMUшникам, и основному майнтайнеру:
> если remotes не сохраняются, то на git.alt копии его
> репозиториев неполноценные, и если слетит диск,
> то не достаточно будет склонировать их с git.alt,
> придется заново тратить время на восстановление
> локальных настроек remotes (а если использовался
> git-svn, то там все вообще печально).
>
> Да и на даче / в походе удобнее -
> не нужно таскать с собой диски
> или тратить время на настройку git-клона.
>

Зачем ? У каждого свои предпочтения по именованию локальных бранчей и не 
надо никому ничего навязывать.

ветка upstream легко восстанавливается из
$cat .gear/tags/list
206e6dc17b4a7f4aaac1f8c87ffdc7cd6e7a0ce6 v4.3

единственная проблема - это понять откуда брать апстрим, и эту 
информацию как раз удобно хранить в watch файле.

Если хочется быстрого восстановления, то можно сделать тривиальный 
скрипт, который посмотрит на локальные настройки (как мейнтейнеру 
хочется хранить апстримную ветку локально и название remote ветки)
и сделает два шага:
1) из .gear/tags/list соорудит ветку upstream
2) из watch файла соорудит remote для upstream

Всё очень просто.

Сложно будет в случае нескольких тарболлов из разных веток и двух remote 
upstream Я с таким где-то сталкивался, но и там можно что-то придумать.