[devel] I: git.altlinux.org: package repository structure

[devel] I: git.altlinux.org: package repository structure

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]

Hi,

Как уже было сказано, gear не накладывает ограничений на внутреннюю
организацию git-репозитория (не считая файла с правилами).
Тем не менее, у меня есть несколько соображений о том, как более
эффективно и удобно организовывать git-репозитории, предназначенные
для хранения пакетов:

+ Одна сущность - один репозиторий.
Не стоит помещать в один репозиторий несколько разных пакетов, за
исключением случаев, когда у этих пакетов есть общий пакет-предок.
Соблюдение этого правила облегчает совместную работу над пакетом,
поскольку не перегруженный репозиторий легче клонировать и в целом
инструментарий git больше подходит для работы с такими репозиториями.
- Отрицательная сторона: несколько сложнее делать "push" и "pull" в
случае, когда репозиториев, которые надо обработать, много.  Впрочем,
push/pull в цикле выручает.

+ Несжатый исходный код.
Сжатый разными архиваторами исходный код (как правило это tarball'ы)
лучше хранить в git-репозитории в несжатом виде.  Изменение файлов,
которые помещены в репозиторий в сжатом виде, менее удобно отслеживать
штатными средствами (git-diff).  Поскольку git хранит объекты в сжатом
виде, двойное сжатие редко приводит к экономии дискового пространства.
Наконец, алгоритм, применяемый для минимизации трафика при обновлении
репозитория по протоколу git, заметно более эффективен на несжатых
данных.  
- Отрицательная сторона: поскольку некоторые виды сжатия одних и тех же
данных могут приводить к разным результатам, может уменьшиться степень
первозданности (нативности) исходного кода.

+ Распакованный исходный код.
Исходный код, запакованный tar/cpio/..., лучше хранить в git-репозитории
в распакованном виде, по тем же причинам (заметно удобнее отслеживать
изменения, существенно меньше трафик при обновлении).
- Отрицательная сторона: поскольку git из информации о владельце, правах
доступа и дате модификации файлов хранит только исполняемость файлов,
любой архив, созданный из репозитория, будет по этим параметрам отличаться
от первозданного.  Помимо потери нативности, изменение прав доступа и
даты модификации может теоретически повлиять на результат сборки пакета.
Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править.

+ Аккуратный changelog.
В changelog релизного commit'а стоит включать соответствующий текст из
changelog'а пакета, как это делают утилиты gear-commit (обёртка к
git-commit, специально предназначенная для этих целей) и gear-srpmimport.
В результате можно будет получить представление об изменениях в пакете,
не заглядывая в spec-файл самого пакета.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.altlinux.org: package repository structure

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

<skipped>

> + Аккуратный changelog.
> В changelog релизного commit'а стоит включать соответствующий текст из
> changelog'а пакета, как это делают утилиты gear-commit (обёртка к
> git-commit, специально предназначенная для этих целей) и gear-srpmimport.
> В результате можно будет получить представление об изменениях в пакете,
> не заглядывая в spec-файл самого пакета.

утилите gear-commit нужно чуть более внятное описание, а то пока не попробуешь, 
не поймёшь, зачем она. Например, так: 

gear-commit - performs git-commit using last changelog entry from spec file

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.altlinux.org: package repository structure

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

> <skipped>
> 
> > + Аккуратный changelog.
> > В changelog релизного commit'а стоит включать соответствующий текст из
> > changelog'а пакета, как это делают утилиты gear-commit (обёртка к
> > git-commit, специально предназначенная для этих целей) и gear-srpmimport.
> > В результате можно будет получить представление об изменениях в пакете,
> > не заглядывая в spec-файл самого пакета.
> 
> утилите gear-commit нужно чуть более внятное описание, а то пока не попробуешь, 
> не поймёшь, зачем она. Например, так: 
> 
> gear-commit - performs git-commit using last changelog entry from spec file

Кстати, я готов несколько расширить это исправление и офоформить его в виде 
патча в репозитории gear. По-моему, это будет хороший повод озвучить 
пример, как делиться патчами. Можешь помочь это оформить пошагово? 

Скажем,
1. Склонировать себе репозиторий с gear (из каталога у ldv@ наверняка. А в общем случае
   как определять, откуда лучше клонировать: какая из копий репозитория, если они 
   есть у нескольких мантейнеров, официальная?) 
2. Внести исправление. ?втащить его в ветку master?, опубликовать свою копию 
   репозитория с этим изменением в своём каталоге.
3. Оповестить мантейнера о своем изменении. Или не оповещать, если он и так сам 
   получит уведомление.

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.altlinux.org: package repository structure

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Wed, Sep 13, 2006 at 12:08:14AM +0400, Kirill Maslinsky wrote:
> <skipped>
> 
> > + Аккуратный changelog.
> > В changelog релизного commit'а стоит включать соответствующий текст из
> > changelog'а пакета, как это делают утилиты gear-commit (обёртка к
> > git-commit, специально предназначенная для этих целей) и gear-srpmimport.
> > В результате можно будет получить представление об изменениях в пакете,
> > не заглядывая в spec-файл самого пакета.
> 
> утилите gear-commit нужно чуть более внятное описание, а то пока не попробуешь, 
> не поймёшь, зачем она. Например, так: 
> 
> gear-commit - performs git-commit using last changelog entry from spec file

Я согласен, автор утилиты, надеюсь, тоже не возражает.
Патчи в любой форме приветствуются.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.altlinux.org: package repository structure

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Я согласен, автор утилиты, надеюсь, тоже не возражает.
> Патчи в любой форме приветствуются.

Патч уже направлен в upstream.

-- 
Rgrds, legion

Re: [devel] I: git.altlinux.org: package repository structure

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

On Wed, Sep 13, 2006 at 12:21:43AM +0400, Kirill Maslinsky wrote:
> > <skipped>
> > 
> > > + Аккуратный changelog.
> > > В changelog релизного commit'а стоит включать соответствующий текст из
> > > changelog'а пакета, как это делают утилиты gear-commit (обёртка к
> > > git-commit, специально предназначенная для этих целей) и gear-srpmimport.
> > > В результате можно будет получить представление об изменениях в пакете,
> > > не заглядывая в spec-файл самого пакета.
> > 
> > утилите gear-commit нужно чуть более внятное описание, а то пока не попробуешь, 
> > не поймёшь, зачем она. Например, так: 
> > 
> > gear-commit - performs git-commit using last changelog entry from spec file
> 
> Кстати, я готов несколько расширить это исправление и офоформить его в виде 
> патча в репозитории gear. По-моему, это будет хороший повод озвучить 
> пример, как делиться патчами. Можешь помочь это оформить пошагово? 
> 
> Скажем,
> 1. Склонировать себе репозиторий с gear (из каталога у ldv@ наверняка. А в общем случае
>    как определять, откуда лучше клонировать: какая из копий репозитория, если они 
>    есть у нескольких мантейнеров, официальная?) 
> 2. Внести исправление. ?втащить его в ветку master?, опубликовать свою копию 
>    репозитория с этим изменением в своём каталоге.
> 3. Оповестить мантейнера о своем изменении. Или не оповещать, если он и так сам 
>    получит уведомление.

А по какому механизму мынтейнер может получить уведомление?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.altlinux.org: package repository structure

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Wed, Sep 13, 2006 at 12:21:43AM +0400, Kirill Maslinsky wrote:
[...]
> > утилите gear-commit нужно чуть более внятное описание, а то пока не попробуешь, 
> > не поймёшь, зачем она. Например, так: 
> > 
> > gear-commit - performs git-commit using last changelog entry from spec file
> 
> Кстати, я готов несколько расширить это исправление и оформить его в виде 
> патча в репозитории gear. По-моему, это будет хороший повод озвучить 
> пример, как делиться патчами. Можешь помочь это оформить пошагово? 
> 
> Скажем,
> 1. Склонировать себе репозиторий с gear (из каталога у ldv@ наверняка. А в общем случае
>    как определять, откуда лучше клонировать: какая из копий репозитория, если они 
>    есть у нескольких мантейнеров, официальная?) 

Пока ещё нет кэширующего репозитория Сизифа, лучше клонировать репозиторий
того мантейнера, который отправил в Сизиф самую свежую сборку этого
пакета.

> 2. Внести исправление. ?втащить его в ветку master?, опубликовать свою копию 
>    репозитория с этим изменением в своём каталоге.
> 3. Оповестить мантейнера о своем изменении. Или не оповещать, если он и так сам 
>    получит уведомление.

Мне практически нечего добавить.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.altlinux.org: package repository structure

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 157 bytes --]

On Wed, Sep 13, 2006 at 03:51:18PM +0400, Alexey Tourbin wrote:
> А по какому механизму мынтейнер может получить уведомление?

По email'у.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: git.altlinux.org: package repository structure

[Anton Farygin]

Dmitry V. Levin wrote:
> On Wed, Sep 13, 2006 at 12:21:43AM +0400, Kirill Maslinsky wrote:
> [...]
>>> утилите gear-commit нужно чуть более внятное описание, а то пока не попробуешь, 
>>> не поймёшь, зачем она. Например, так: 
>>>
>>> gear-commit - performs git-commit using last changelog entry from spec file
>> Кстати, я готов несколько расширить это исправление и оформить его в виде 
>> патча в репозитории gear. По-моему, это будет хороший повод озвучить 
>> пример, как делиться патчами. Можешь помочь это оформить пошагово? 
>>
>> Скажем,
>> 1. Склонировать себе репозиторий с gear (из каталога у ldv@ наверняка. А в общем случае
>>    как определять, откуда лучше клонировать: какая из копий репозитория, если они 
>>    есть у нескольких мантейнеров, официальная?) 
> 
> Пока ещё нет кэширующего репозитория Сизифа, лучше клонировать репозиторий
> того мантейнера, который отправил в Сизиф самую свежую сборку этого
> пакета.

Т.е. - в итоге будет единое место, где лежит всё самых последних версий 
? т.е. - некий автоматический merge от всех мантейнеров ?

> 
>> 2. Внести исправление. ?втащить его в ветку master?, опубликовать свою копию 
>>    репозитория с этим изменением в своём каталоге.
>> 3. Оповестить мантейнера о своем изменении. Или не оповещать, если он и так сам 
>>    получит уведомление.
> 
> Мне практически нечего добавить.

а у меня всё равно вопросы остались ;(
- как пакет в итоге попадёт в Sisyphus, когда вступит в действие 
механизм сборки пакетов из gear ?
- что делать, если мантейнер ушёл в запой, а NMU сделать нужно ?

Rgds,
Rider

Re: [devel] I: git.altlinux.org: package repository structure

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

* Anton Farygin <rider@> [060913 16:38]:
> Т.е. - в итоге будет единое место, где лежит всё самых последних версий 
> ? т.е. - некий автоматический merge от всех мантейнеров ?
Не merge от всех мантейнеров, а копия того репозитария из
которого собирался пакет.  Мержить себе чужие изменения будут
сами мантейнеры.

> - как пакет в итоге попадёт в Sisyphus, когда вступит в действие 
> механизм сборки пакетов из gear ?
Очевидно, при помощи некоего механизма ;-)

> - что делать, если мантейнер ушёл в запой, а NMU сделать нужно ?
Точно также как в предыдущем пункте ;-)

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]