On Wed, Nov 26, 2003 at 11:27:52AM +0300, Stanislav Ievlev wrote:

 > Ну допустим. Приходит в Сизиф новый bind10. Лежит себе в .incoming -
 > _небольшое_ количество разработчиков (не админов) тестируют его в своих
 > конфигурациях. По каким-то, до сих пор не сформулированным критериям,
 > решают, что он надёжный.
 > Пакет переезжает в Сизиф. админ X делает dist-upgrade по крону ... и
 > опаньки. Оказывается в его очень специфической настройке bind, bind10 не
 > работает. Просто разработчик не админ и не знал, что такие ситуации
 > существуют. Цель .incoming не выполнена.

Цель -- _увеличить надёжность_. То есть _уменьшить вероятность сбоя_, а не
свести её к нулю (что, как я уже говорил, принципиально невозможно при
нынешней практике писать софт на си).
 
 > Так что вопрос остаётся. Вы знаете критерий оценки надёжности пакета.
 > Пользуясь которым _разработчики_ могли бы признавать пакет годным для
 > перемещения. Ибо как понимаете если админ начинает смотреть .incoming, то
 > зачем он нужен. Проще не проводить синхронизацию рабочих серверов каждый
 > день. Как правило это и не нужно.

Предположим в данный конкретный день мне надо сделать обновление. А там
как раз сейчас валяется какой-нибудь пакет, которому 2 дня назад уже
выставили в BTS block-bug сборки. И что тогда делать? Ждать пока баг
закроют?

Смотреть incoming должны не админ, а именно разработчики. Или те админы,
которые по каким-то причинам считают нужным использовать в своей работе
Сизиф, и обслуживают большое количество машин (тогда им имеет смысл
участвовать в этом тестировании).

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

Или нечто скорострельное и самонаводящееся.
 
 > Вот тут мы дошли до сути проблемы. Сизиф это _не дистрибутив_, а репозитарий.
 > Давайте не будем переворачивать всё с ног на голову и переформулируем
 > проблему так. Нужен способ полуавтоматического выпуска дистрибутивов
 > скажем раз в месяц. Мы готовы к этому? Я думаю, что при текущем состоянии
 > инфраструктуры нет. Сначала нужен реальный _репозитарий_ a-la sandman.
 > Почему sandman-репозитарий не внедрён до сих пор, хотя разговоры между
 > Сашей и Димой были уже неоднократно, надо ,как я понимаю, спрашивать у
 > них.

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

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

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

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

-- 
С уважением, Денис

http://freesource.info