[devel] ACL in branches

[Alexey Tourbin]

On Wed, Mar 11, 2009 at 01:56:45AM +0600, Mikhail Gusarov wrote:
> Twas brillig at 22:52:04 10.03.2009 UTC+03 when at на altlinux.ru did gyre and gimble:
> 
>  AT> Мои оппоненты утверждают, что принципиально важно вручную
>  AT> протестировать пакет сразу после сборки в girar-builder, но до
>  AT> попадания в репозитарий.
> 
>  AT> Я оппонирую, что это не принципиально важно: можно протестировать
>  AT> пакет чуть раньше (после сборки в собственном хешере) или чуть
>  AT> позже (когда пакет уже пройдёт в сизиф).  А тестирование именно
>  AT> "здесь и сейчас" дополнительно ничего не дает.
> 
> В такой постановке - да. Но как я помню - вопрос ставился немного
> по-другому.

Вопрос ставился так.  Оппоненты хотят иметь задание, которое собирается,
но автоматически не проходит.  Когда задание собралось, им отправляется
уведомление: "задание собралось но не прошло; тестируйте вручную и
подтверждайте проводить или нет".  Оппоненты тестируют вручную и говорят
"окей, проводите".  На что сборочница отвечает: "извините, пакеты as is
взять нельзя, их пришлось пересобрала, тестируйте ещё раз".  И т.д.

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

> Есть сборки, которые не имеет смысла пропускать в сизиф, потому что
> заранее известно, что они не готовы. Скажем (если взять те пакеты, на
> которых приводились примеры), там отсутствует путь апгрейда
> пользовательских данных с Сизифной версии на новую.  Или автор сборки
> имеет "особое мнение", отличное от мейнтейнера сизифной версии. Или
> что-то ещё.

> Такой people-на-стероидах.

Это другой контекст спора, который касался "персональных дедалов".
Впрочем, не исключено, что эти конексты связаны (и ещё более не
исключено, что мы их смешиваем или путаем).

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

Можно собирать у себя в хешере и тестировать.  Я так делаю для многих
своих пакетов, в которых нет 'make test'.  А пакеты с 'make test' стал
всё чаще отправлять на сборку без предварительного тестирования в
хост-системе.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090310/4a740013/attachment.bin>