[sisyphus] Re: [POLICY] Sisyphus

[Денис Смирнов]

On Tue, Jan 27, 2004 at 09:25:11PM +0200, Michael Shigorin wrote:

 > Ышшо как собирают.  Думаю, не сильно ошибусь, если сравню hasher
 > с каким seti на home -- "поставь и пили" :)

Опаньки. Тогда просветите меня -- собраные у себя в hasher пакеты просто
заливаются потом в incoming/BTE? Или как?
 
 > Здесь есть момент свежести пакетной базы, используемой для
 > сборки.  И вот здесь актуален доступ ко сборочным серверам, ну
 > или повышение нагрузки на incoming@ за счет тех пакетов, которые
 > не собраны в sandman/hasher (и залитых в полном составе
 > бинарников с исходниками).

Я несколько не понимаю: какое поведение мантейнера является наилучшим,
с точки зрения уменьшения нагрузки на incoming@ ?
 
 >> теоретически, мы можем автоматически пытаться пересобрать
 >> пакет, как только появляется новый, из необходимых в сборочной
 >> среде.
 > В качестве теста?  Могу ошибаться, но мне кажется, QA Team Robot
 > почти этим и занимается -- с поправкой на _свою_ периодичность.

Я имел в виду вариант с акцентом не на периодичность, а на необходимость
(вычисляемую по зависимостям).

Кстати вопрос к QA Team: QA Team Robot просто собирает всё подряд с
какой-то периодичностью, или есть какая-то более сложная логика?

 >> Проблема в том, что Сизиф очень большой, и пересобирать при
 >> каждом чихе его нереально вообще (разве что кто-нибудь не
 >> подарит для этих целей кластерчик).
 > (приходят в голову всякие циклические сборочные зависимости...)

Угу... А насчёт их было бы интересно попробовать их действительно
нарисовать и посмотреть. Может быть возможно часть из них разрулить.
 
 >> И вот для решения именно этой проблемы и можно вводить
 >> автоматическую заморозку с любым выбраным интервалом.
 > Так это скорее как раз вопрос QA, а не main loop().  Именно в
 > силу постепенности изменений между ТП.

Они разве не должны быть связаны?
 
 >> Ага. Вопрос вот в другом -- а если обновился bash, то нам действительно
 >> надо пересобирать всю систему?
 > Вооот.  Тем паче что изменения могут быть и не технологическими.
 > Когда нет разрыва (такого, как при soname change, new layout,
 > переразбили группу пакетов => поплыли builddeps).  Не уверен, что
 > все случаи, когда пересборка _необходима_, вообще обвешиваются
 > тестами и что на данном этапе это продуктивнее $maintainer.

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

От варианта сизифа для использования 100% собираемость никто _требовать_ и
не будет. Требовать будут 100% устанавливаемость, а её как раз скриптом
обеспечить более-менее легко.
 
 >> Не будет никогда дискретности в разработке. У каждого человека
 >> свои особенности стиля работы, мне вон ничего не помешало
 >> залить новый пакет 1 января в 7 утра :) Жёсткое разбиение
 >> хорошо для стабильности но цену платить за эту стабильность
 >> слишком большую.
 > Да.  Здесь стоит различать конторы с ватманом и volunteer
 > projects, у которых (к счастью или наоборот) свои реалии.

Угу. Собственно поэтому надёжность можно обеспечить только одним способом
-- должно быть минимум возможностей что-то сломать, причём большинство
поломок должно либо самоустраняться, либо мантейнер должен получить
внятное объяснение как исправить проблему (тоже от скрипта, разумеется).

-- 
С уважением, Денис

http://freesource.info