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

[Anton Farygin <rider@altlinux.com>]

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

Ой ой ой... господа, я _не рекоменду_ использовать Sisyphus на серверах 
любого маштаба.

> 
> Конечная цель моего предложение -- довести надёжность Сизифа до такой
> степени, чтобы можно было себе позволить по крайней мере на своей личной
> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
> грозить увольнением.

Собственно а зачем Sisyphus ???

Есть же Master 2.2 - его + updates должно хватить.

>  
>  >> * .classic, который и применяется
>  >>     _пользователями_ Sisyphus.
>  >>       (в т.ч. и разработчиками Sisyphus на хостах, которые можно
>  >>       себе позволить / требуется держать на Sisyphus, но которые
>  >>       желательно иметь в работоспособном состоянии),
>  >> при условии минимальных изменений в текущей схеме.  
>  > До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги.
> 
> de-facto динамичный репозиторий пакетов востребован конечными
> пользователями (в первую очередь этими пользователями являются
> разработчики и тестеры, но далеко не только они).
> 
> Поэтому можно либо закрывать глаза на такое его использование, либо
> искать принимать меры, которые позволят убить сразу уйму зайцев без
> негативных последствий для тех, кто привык и кому нравится нынешний
> механизм разработки.
>  
>  > Как показывает практика что пакет может лежать в daedalus. Большиство
>  > знает что там unstable и не пользуется им. Когда пакет приходит из
>  > daedalus в Cизиф там обнаруживаются проблемы.
> 
> Это всё потому, что даже Сизиф не является более-менее надёжным
> дистрибутивом. Daedalus в этом смысле рассматривается как "лучше я сразу
> сделаю rm -rf /, результат тот же, а работы меньше".

Sisyphus вообще не дистрибутив.

> 
> Я же предлагаю отслоить от Сизифа надёжную его часть, и позволить людям,
> которым это необходимо, использовать именно его.

Зачем ?

>  
>  > Так в где гарантии что на пакет из incoming хоть кто-нибудь будет смотреть. 
>  > Для начала надо приучить _разработчиков_ пользоваться deadalus иначе
>  > просто будет добавлен новый совершенно неиспользуемый репозитарий.
> 
> Это равносильно попытке приучить людей тестировать на себе новые
> лекарства. Daedalus это экспериментальный дистрибутив, а никак не
> нестабильный.

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

>  
>  > > > 3. кто всё это будет поддерживать.
>  > > Скрипты.
>  > Не всё можно охватить скриптами.
>  > Даже сейчас при наличии большого количества скриптов приходится иногда
>  > incoming переводить на ручное управление.
> 
> Все те изменения, которые я предложил здесь, отлично скриптуемы.

Нет. Не скриптуемы до тех пор, пока в Sisyphus не появятся кем-то 
(неважно кем) разработанный набор скриптов.
И пока этот набор скриптов не решит использовать наш incoming@

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

Не.. не все так просто.... для начала рекомендую попробовать вычислить 
набор provides для бинарных пакетов, которые получаются из src.rpm

>  
>  >> Для "заглушки" критерием может быть
>  >>   время модификации, от которого прошло N часов (24?);
>  >>     это даст эффект "админ должен быть в меру тормознутым" -- у
>  >>     разработчиков будет фора в эти N часов на dist-upgrade и
>  >>     использование пакета.
>  > Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
>  > не напарывался - то не факт что через N часов она самоликвидируется.
> 
> За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не
> будет. Выбирать это самое N пока придётся опытным путём, потом можно
> анализировать статистику.

Как показывает практика - большинство ошибок будет выявляться уже 
_после_ перемещения пакета, ибо для того, что бы его проверить в 
нестабильном репозитарии нужно неопределенно большое количество 
пользователей этого пакета, ежедневно обновляющихся из _нестабильного_ 
репозитария. Unreal.

Rgds,
Rider