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

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 4175 bytes --]

On Wed, Nov 26, 2003 at 03:45:05PM +0300, Anton Farygin wrote:

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

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

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

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

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

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

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

Тут есть один нюанс, с которым я пока не знаю как бороться. Дело в том,
что, например, basesystem я тестировать на себе не хочу. А вот тот же php
и apache -- хочу. Потому как лучше я их сам оттестирую, чем буду иметь
проблемы при обновлении.

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

http://freesource.info


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]