From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 26 Nov 2003 17:03:58 +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: <20031126140358.GC27949@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> <3FC4A051.2070302@altlinux.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline In-Reply-To: <3FC4A051.2070302@altlinux.com> 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 14:22:00 -0000 Archived-At: List-Archive: List-Post: --+nBD6E3TurpgldQp Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xLLO9yLOUeHSdCYRAn1YAJ49vV/e47dRQZFsaXJhojwHNoXJwACgqMJ0 6bRXmwEnUrELJ+LJ6UZ/org= =5M2u -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp--