[devel] об обсуждении подходов к оценке надёжности Sisyphus

Ср Ноя 26 11:27:52 MSK 2003

On Wed, Nov 26, 2003 at 01:59:16AM +0300, Денис Смирнов wrote:
> On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote:
> 
>  >>> и что такое "надёжность sisyphus" по-определению.
>  >> Не знаю; не вводил.
>  > нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus.
> 
> У меня есть. Надёжность это величина равная 1-<ненадёжность>, а
> ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде
> неработоспособного сервера (т.е. не выполняющего свои функции так же
> хорошо, как до апгрейда).
Ну допустим. Приходит в Сизиф новый bind10. Лежит себе в .incoming -
_небольшое_ количество разработчиков (не админов) тестируют его в своих
конфигурациях. По каким-то, до сих пор не сформулированным критериям,
решают, что он надёжный.
Пакет переезжает в Сизиф. админ X делает dist-upgrade по крону ... и
опаньки. Оказывается в его очень специфической настройке bind, bind10 не
работает. Просто разработчик не админ и не знал, что такие ситуации
существуют. Цель .incoming не выполнена.

Так что вопрос остаётся. Вы знаете критерий оценки надёжности пакета.
Пользуясь которым _разработчики_ могли бы признавать пакет годным для
перемещения. Ибо как понимаете если админ начинает смотреть .incoming, то
зачем он нужен. Проще не проводить синхронизацию рабочих серверов каждый
день. Как правило это и не нужно.
> 
> Конечная цель моего предложение -- довести надёжность Сизифа до такой
> степени, чтобы можно было себе позволить по крайней мере на своей личной
> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
> грозить увольнением.
>  
>  >> * .classic, который и применяется
>  >>     _пользователями_ Sisyphus.
>  >>       (в т.ч. и разработчиками Sisyphus на хостах, которые можно
>  >>       себе позволить / требуется держать на Sisyphus, но которые
>  >>       желательно иметь в работоспособном состоянии),
>  >> при условии минимальных изменений в текущей схеме.  
>  > До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги.
> 
> de-facto динамичный репозиторий пакетов востребован конечными
> пользователями (в первую очередь этими пользователями являются
> разработчики и тестеры, но далеко не только они).
> 
> Поэтому можно либо закрывать глаза на такое его использование, либо
> искать принимать меры, которые позволят убить сразу уйму зайцев без
> негативных последствий для тех, кто привык и кому нравится нынешний
> механизм разработки.
Как бы при таком массовом убийстве зайцев и себя не задеть. Ибо как
известно чтобы убить разбегающихся зайцев одним махом нужна бомба.
>  
>  > Как показывает практика что пакет может лежать в daedalus. Большиство
>  > знает что там unstable и не пользуется им. Когда пакет приходит из
>  > daedalus в Cизиф там обнаруживаются проблемы.
> 
> Это всё потому, что даже Сизиф не является более-менее надёжным
> дистрибутивом. Daedalus в этом смысле рассматривается как "лучше я сразу
> сделаю rm -rf /, результат тот же, а работы меньше".
> 
> Я же предлагаю отслоить от Сизифа надёжную его часть, и позволить людям,
> которым это необходимо, использовать именно его.
Вот тут мы дошли до сути проблемы. Сизиф это _не дистрибутив_, а репозитарий.
Давайте не будем переворачивать всё с ног на голову и переформулируем
проблему так. Нужен способ полуавтоматического выпуска дистрибутивов
скажем раз в месяц. Мы готовы к этому? Я думаю, что при текущем состоянии
инфраструктуры нет. Сначала нужен реальный _репозитарий_ a-la sandman.
Почему sandman-репозитарий не внедрён до сих пор, хотя разговоры между
Сашей и Димой были уже неоднократно, надо ,как я понимаю, спрашивать у
них.
>  
>  > Так в где гарантии что на пакет из incoming хоть кто-нибудь будет смотреть. 
>  > Для начала надо приучить _разработчиков_ пользоваться deadalus иначе
>  > просто будет добавлен новый совершенно неиспользуемый репозитарий.
> 
> Это равносильно попытке приучить людей тестировать на себе новые
> лекарства. Daedalus это экспериментальный дистрибутив, а никак не
> нестабильный.
Опять та же принципиальная ошибка. Daedalus - это не дистрибутив, а
репозитарий.
>  
>  > > > 3. кто всё это будет поддерживать.
>  > > Скрипты.
>  > Не всё можно охватить скриптами.
>  > Даже сейчас при наличии большого количества скриптов приходится иногда
>  > incoming переводить на ручное управление.
> 
> Все те изменения, которые я предложил здесь, отлично скриптуемы.
Только если есть критерий. Его пока нет.
>  
>  > Нет никаких гарантий, что нетривиальные замены библиотек,
>  > преименование/образование подпакетов можно будет полностью охватить скриптами.
> 
> Образование подпакетов легко, потому как работать система будет на уровне
> src.rpm, и сколько там подпакетов ей будет всё равно. Переименование --
> отлично сработает само, так как новый помещаемый в дистрибутив пакет (с
> другим именем) должен конфликтовать со старым (насколько я помню), таким
> образом, если у этих пакетов один и тот же мантейнер, то он может быть
> вынесен скриптом автоматически.
Ну допустим src.rpm. Тогда, проверки придётся делать по 45000 пакетам при
добавлении 10 пакетов. Каждое добавление в Сизиф будет занимать порядка 20
минут. Это не реально.
>  
>  >> Для "заглушки" критерием может быть
>  >>   время модификации, от которого прошло N часов (24?);
>  >>     это даст эффект "админ должен быть в меру тормознутым" -- у
>  >>     разработчиков будет фора в эти N часов на dist-upgrade и
>  >>     использование пакета.
>  > Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
>  > не напарывался - то не факт что через N часов она самоликвидируется.
> 
> За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не
> будет. Выбирать это самое N пока придётся опытным путём, потом можно
> анализировать статистику.
Флаг в руки ;)
Пока ещё никто такого делать не научился  (определять среднестатистическое
обнаружение баги) ;)
Было бы так. Не находили бы баги в 2.2 спустя несколько лет после выхода 2.4?

Если за N принимать среднее - то будет срабатывать пример с bind10.
>  
> -- 
> С уважением, Денис
> 
> http://freesource.info
> 


> _______________________________________________
> Devel mailing list
> Devel на altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel