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

[Anton Farygin]

Денис Смирнов wrote:
> On Wed, Nov 26, 2003 at 03:45:05PM +0300, Anton Farygin wrote:
> 
>  >> Конечная цель моего предложение -- довести надёжность Сизифа до такой
>  >> степени, чтобы можно было себе позволить по крайней мере на своей личной
>  >> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
>  >> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
>  >> грозить увольнением.
>  > Собственно а зачем Sisyphus ???
>  > Есть же Master 2.2 - его + updates должно хватить.
> 
> На сервере, в большинстве случаев, да. Однако во многих оказывается
> необходимость пол-сизифа бэкпортить.

ну так это лучше чем держать кучу непонятных репозитариев.

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


Самоубийцы должны быть на самообслуживании... все остальные - Welcom 2 
Sisyphus, постоянно нестабильную среду разработки.


>  
>  >> Это равносильно попытке приучить людей тестировать на себе новые
>  >> лекарства. Daedalus это экспериментальный дистрибутив, а никак не
>  >> нестабильный.
>  > Это не дистрибутив, а репозитарий.. и именно экспериментальный... есть 
>  > много людей, которые хотят тестировать новые лекарства, если этим самые 
>  > лекарства могут спасти их от неминуемой смерти или ятжелоизлечимой болезни.
> 
> Фишка в том, что у нас есть только Мастер (в который попадают пакеты в том
> числе после freeze, и который тажже далёк от идеала в плане надёжности), и
> Сизиф, использование которого сами разработчики считают склонностью к
> суициду. Я же предлагаю ввести дополнительную прослойку между Сизифом и
> Мастером.

Ага... называется профессиональный суицид чужими руками...  нет. Как-то 
это выглядит намного хуже, чем введение новых правил в sisyphus_check.

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

Ясно что? Что не будет использовать или что будет использовать?


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

А как иначе узнать реальный список пакетов, которые получаются из этого 
src.rpm ?

Да, еще нужно вычислить Obsoletes...

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

Ну так тестируйте из Sisyphus, вешайте баги, убивайте ошибки, 
пересобирайте для Master 2.2 - и вперед !!!


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


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

Нет, ибо для ее выполнения придется написать некоторый набор скриптов, 
реализующий такую функциональность, что до конца жизни придется 
исправлять ошибки в своих собственных скриптах.

Rgds,
Rider