Re: [devel] pockets

["Dmitry V. Levin" <ldv@altlinux.org>]

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

Hi,

On Tue, Mar 16, 2010 at 09:41:03PM +0300, Alexey Tourbin wrote:
> Альтернативное мнение: contrib не нужен, pocket'ы не нужны.

В связи с pockets могу привести аналогию.  Когда-то достаточно давно
пакеты в Сизиф собирались на сервере по имени altair, прямо в
хост-системе.  Помимо тех, кто имел возможность собрать пакет для
тестирования непосредственно на сервере, никто не мог знать заранее,
соберётся ли отправляемый в Сизиф пакет, и если соберётся, то насколько
полученный результат будет отличаться от собранного и протестированного
локально.  Потом (уже почти 7 лет назад) появился инструмент для
построения воспроизводимой сборочной среды.  Каждый мейнтейнер получил
возможность собирать и тестировать локально пакет в такой же среде, в
которой этот пакет собирается в Сизиф.

Сейчас история повторяется в другой форме: система, собирающая пакеты в
Сизиф, помимо самой сборки, выполняет нетривиальную работу по проверке
собранных пакетов и помещению прошедших проверки пакетов в репозиторий.
Несмотря на то, что исходный код этой системы публично доступен, далеко
не каждый мейнтейнер может развернуть эту систему локально.  Кроме
того, репозиторий, на котором производится централизованная сборка,
может отличаться от репозитория, на котором мейнтейнер тестировал свою
локальную сборку.

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

Какие видны варианты решения первого вопроса?  Либо girar/girar-builder
должен стать не более сложным в развёртывании и использовании
инструментом, чем hasher, либо сборочная система должна предоставлять
т.н. карманы: интерфейс для ветвления Сизифа, коллективной сборки
заданий в репозитории мейнтейнеров, и последующей интеграции в Сизиф.  

Какой вариант кажется вам более перспективным?  Имело ли смысл 7 лет
назад выделить каждому мейнтейнеру shell account на сборочном сервере
вместо того, чтобы реализовать hasher?  В какой степени эта аналогия
переносима на нашу нынешнюю ситуацию?


-- 
ldv

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