[sisyphus] Re: [POLICY] Sisyphus

[Denis Smirnov]

On Mon, Jan 26, 2004 at 06:48:22PM +0300, info wrote:

 > Не должно быть этой "первой степени"!!! Мало кто  успеет 
 > обновиться, собраться и оттестироваться всего лишь за сутки. 
 > Упаковщий должен иметь _достаточный_ и вдобавок заранее 
 > известный ему период времени, относительно которого он уверен: 
 > за этот период окружение не изменится.

Дык тогда и окажется, что все сделали свои пакеты собирающимися и
работающими на сизифе недельной давности. А друг с другом они, увы, могут
оказаться и неработоспособны. Увеличение кванта времени само по себе не
панацея.

_Девелоперы_ должны иметь возможность получить у себя в любой момент
_самые_ свежие сборки (хоть с 5-и минутным интервалом). Попадать же к
юзверям должны оттестированые сборки.

Кроме того обновиться, собрать и оттестировать пакет за сутки можно.
Моя домашняя машина всегда обновлена по-максимуму, ибо ночью качаются все
необходимые обновления, а днём, когда мне удобно, я могу их поставить (или
не поставить).
 
 >>> Третий день - тестирование собранного, и слив собранных
 >>> пакетов. Получаем minimum minimorum для кванта времени -
 >>> трое суток.
 >> На самом деле и между ними могут быть задержки.  Но в общем
 >> -- неделя :)
 > Да, оптимум - неделя. 

Оптимум -- 0. А для попадания к юзверам нужно выбирать индивидуальное
время тестирования каждого пакета.
 
 >> См. тж. apt-cache(1) по поводу dotty.  Оно без учета
 >> важности, и не факт, что _из_ нее надо исходить -- а не
 >> считать ее как сумму зависимостей от данного пакета в
 >> каком-то виде.
 > Не знаю, можно ли оценивать важность алгебраическим методом, как 
 > сумму зависимостей (если правильно понял)... Важность скорее 
 > вытекает из топологии пакетов. 

Топологию вполне можно оценить (количество косвенных зависимостей).

А можно вообще использовать алгоритм аналогичный используемый поисковиками
для вычисления PageRank.

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

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

И вот для решения именно этой проблемы и можно вводить автоматическую
заморозку с любым выбраным интервалом.

 > Причем - важный момент - та схема, о которой я говорю, вовсе не 
 > означает, что между пакетами разных уровней непременно должна 
 > быть прямая зависимость. Тот же KDE будет, в общем случае, 
 > работать на самых разных версиях того же Xfree. Но если 
 > обновился XFree - (а тем более glibc) - то полезно пересобрать 
 > KDE. Так сказать, во избежание....

Ага. Вопрос вот в другом -- а если обновился bash, то нам действительно
надо пересобирать всю систему?
 
 > Так что речь не о зависимости в программистском смысле слова, а 
 > о зависимости, так сказать, в административном. 

Э... В таком случае нам после каждого нового ядра всю систему
пересобирать. Вот зависимости в программистском смысле (buildreq) должны
являться поводом пересборки.

Только вот такую массовую пересборку даже еженедельную тяжко, наверное,
делать (интересно -- сколько времени нужно нынешнему сборочному для
пересборки всего сизифа?).

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

 > "сизиф Б" - это тоже практически тот же самый сизиф, что и 
 > сегодня, а который заливаются пакеты по мере поступления 
 > поступления, но к которому имеют доступ _для_скачивания_ только 
 > упаковщики; причем для упаковщиков особо оговаривается, дабы 
 > они старались собирать свои пакеты на "сизифе А", а новые 
 > пакеты из "сизифа Б" брали только если уж край и без них 
 > никуда.

Опять ограничения... Не хорошо. Пусть лучше как раз у девелоперов будет
самая распосленяя версия (иначе кто эти версии тестировать будет?).
 
 > А если еще явно указывать пользователям - "до обновления 
 > осталось столько-то времени" - то они и сами решат, стоит 
 > запускать обновление из сизифа А за 5 минут до обновления 
 > самаого сизифа, или нет :-)))

Не будет никогда дискретности в разработке. У каждого человека свои
особенности стиля работы, мне вон ничего не помешало залить новый пакет 1
января в 7 утра :) Жёсткое разбиение хорошо для стабильности но цену
платить за эту стабильность слишком большую.
 
 >> т.е. отдельная компонента Sisyphus, которая:
 >> - принимает в себя свежезалитые пакеты наиболее оперативно;
 >> - рекомендована к применению разработчиками;
 >> - дополнительно тестируется опытными пользователями.
 > Вот это и есть сизиф Б, с той только поправкой, что сборка новых 
 > пакетов идет, _как_правило_, не на нем, а на сизифе А.

Есть два вида сборок -- на машине мантейнера и на сборочной системе. О
какой мы сейчас говорим?
 
 > Вы имеете в виду конфликты между файлами разных пакетов - как, 
 > например, lesstiff и openmotif? Ну, надо подумать... Десяток 
 > машин ставить негоже, дороговато будет, а вот несколько 
 > chrooted вариантов сизифа на одной мощной машине - почему бы и 
 > нет?

Зачем мне для сборки моего маленького простого тупого fstyp сборочное
окружение с lesstif? 
 
-- 
С уважением, Денис

http://freesource.info