From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 26 Nov 2003 14:15:14 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?B?z8Igz8LT1dbExc7J?= =?koi8-r?B?ySDQz8TIz8TP1yDLIM/Dxc7LxSDOwcSj1s7P09TJ?= Sisyphus Message-ID: <20031126111514.GA20469@localhost.localdomain> References: <20031125001230.D78905@elefant.dgtu.donetsk.ua> <20031125072830.GE2421@basalt.office.altlinux.org> <20031125094848.GH10424@osdn.org.ua> <20031125122911.GA9809@basalt.office.altlinux.org> <20031125225916.GE19276@localhost.localdomain> <20031126082752.GD24420@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <20031126082752.GD24420@basalt.office.altlinux.org> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 11:15:32 -0000 Archived-At: List-Archive: List-Post: --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xItC9yLOUeHSdCYRAn1IAJ9AMGti9jXEgFMOe/yrD9aqK6bk5ACfYO1P uUrYwuw+y7KCjRqk0cNIUnM= =3tT/ -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf--