[devel] об обсуждении подходов к оценке надёжности Sisyphus
Stanislav Ievlev
=?iso-8859-1?q?inger_=CE=C1_altlinux=2Eorg?=
Ср Ноя 26 15:15:42 MSK 2003
On Wed, Nov 26, 2003 at 02:15:14PM +0300, Денис Смирнов wrote:
> > решают, что он надёжный.
> > Пакет переезжает в Сизиф. админ X делает dist-upgrade по крону ... и
> > опаньки. Оказывается в его очень специфической настройке bind, bind10 не
> > работает. Просто разработчик не админ и не знал, что такие ситуации
> > существуют. Цель .incoming не выполнена.
>
> Цель -- _увеличить надёжность_. То есть _уменьшить вероятность сбоя_, а не
> свести её к нулю (что, как я уже говорил, принципиально невозможно при
> нынешней практике писать софт на си).
ради любопытства: причём здесь си.
Дабы минимизировать объём теста, пропущу то что далее.
Итак, мне понятна мысль - сделать два Сизифа с "запаздыванием по времени".
Но до сих пор не понятно почему для этого нельзя использовать связку
Сизиф-Дедал. По моему разумению результат от введения ещё одного Сизифа
сопоставим (при значительно меньших затратах) от более эффективного
использования Дедала.
Ключевой момент в моей позиции - мы получим ещё один Дедал ибо люди (будь
то пользователи или разработчики) будут сознательно или несознательно
избегать использования пакетов, объявленных как нестабильные. Зачем нам
ещё одна прослойка которая будет использоваться на 30%.
Если уж нужен какой "отстойник" пакетов - то для этих целей можно
использовать уже существующий incoming: он доступен на чтение всем
разработчикам, а забирать в Сизиф можно только пакеты которые отлежались
там например 3 дня. Результат будет одинаковый.
Много пакетов придётся проверять в скрипте: например может появиться
принципиально новый пакет который просто обсолетит другой пакет в Сизифе.
Подробная информация о списке рассылки Devel