From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 26 Nov 2003 01:59:16 +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: <20031125225916.GE19276@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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <20031125122911.GA9809@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: Tue, 25 Nov 2003 22:59:18 -0000 Archived-At: List-Archive: List-Post: --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote: >>> и что такое "надёжность sisyphus" по-определению. >> Не знаю; не вводил. > нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus. У меня есть. Надёжность это величина равная 1-<ненадёжность>, а ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде неработоспособного сервера (т.е. не выполняющего свои функции так же хорошо, как до апгрейда). Конечная цель моего предложение -- довести надёжность Сизифа до такой степени, чтобы можно было себе позволить по крайней мере на своей личной машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет грозить увольнением. >> * .classic, который и применяется >> _пользователями_ Sisyphus. >> (в т.ч. и разработчиками Sisyphus на хостах, которые можно >> себе позволить / требуется держать на Sisyphus, но которые >> желательно иметь в работоспособном состоянии), >> при условии минимальных изменений в текущей схеме. > До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги. de-facto динамичный репозиторий пакетов востребован конечными пользователями (в первую очередь этими пользователями являются разработчики и тестеры, но далеко не только они). Поэтому можно либо закрывать глаза на такое его использование, либо искать принимать меры, которые позволят убить сразу уйму зайцев без негативных последствий для тех, кто привык и кому нравится нынешний механизм разработки. > Как показывает практика что пакет может лежать в daedalus. Большиство > знает что там unstable и не пользуется им. Когда пакет приходит из > daedalus в Cизиф там обнаруживаются проблемы. Это всё потому, что даже Сизиф не является более-менее надёжным дистрибутивом. Daedalus в этом смысле рассматривается как "лучше я сразу сделаю rm -rf /, результат тот же, а работы меньше". Я же предлагаю отслоить от Сизифа надёжную его часть, и позволить людям, которым это необходимо, использовать именно его. > Так в где гарантии что на пакет из incoming хоть кто-нибудь будет смотреть. > Для начала надо приучить _разработчиков_ пользоваться deadalus иначе > просто будет добавлен новый совершенно неиспользуемый репозитарий. Это равносильно попытке приучить людей тестировать на себе новые лекарства. Daedalus это экспериментальный дистрибутив, а никак не нестабильный. > > > 3. кто всё это будет поддерживать. > > Скрипты. > Не всё можно охватить скриптами. > Даже сейчас при наличии большого количества скриптов приходится иногда > incoming переводить на ручное управление. Все те изменения, которые я предложил здесь, отлично скриптуемы. > Нет никаких гарантий, что нетривиальные замены библиотек, > преименование/образование подпакетов можно будет полностью охватить скриптами. Образование подпакетов легко, потому как работать система будет на уровне src.rpm, и сколько там подпакетов ей будет всё равно. Переименование -- отлично сработает само, так как новый помещаемый в дистрибутив пакет (с другим именем) должен конфликтовать со старым (насколько я помню), таким образом, если у этих пакетов один и тот же мантейнер, то он может быть вынесен скриптом автоматически. >> Для "заглушки" критерием может быть >> время модификации, от которого прошло N часов (24?); >> это даст эффект "админ должен быть в меру тормознутым" -- у >> разработчиков будет фора в эти N часов на dist-upgrade и >> использование пакета. > Как и кем определяются эти N часов. Если была бага на которую кто-то ещё > не напарывался - то не факт что через N часов она самоликвидируется. За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не будет. Выбирать это самое N пока придётся опытным путём, потом можно анализировать статистику. -- С уважением, Денис http://freesource.info --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/w97D9yLOUeHSdCYRAlfBAJ9F9DnML4KUl8aTM5yfpUScQK1l8QCeMVXo eHaqR1eGE5FuBTWZ3INbYrc= =urPr -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd--