From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 22 Nov 2003 00:55:54 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?B?7sHEo9bOz9PU?= =?koi8-r?Q?=D8?= Sisyphus Message-ID: <20031121215554.GA5696@localhost.localdomain> References: <20031113233031.049e4323.xmm@altlinux.ru> <20031113234248.2c914764.nikon@e-nk.ru> <20031113224456.GB28958@localhost.localdomain> <20031114124750.GE8394@osdn.org.ua> <20031114152146.GB29311@localhost.localdomain> <20031117083502.GA18832@osdn.org.ua> <20031117212959.GC30633@localhost.localdomain> <20031120145103.GF9136@osdn.org.ua> <20031120173326.GE7822@localhost.localdomain> <20031121160009.GL9136@osdn.org.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20031121160009.GL9136@osdn.org.ua> 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: Fri, 21 Nov 2003 23:05:40 -0000 Archived-At: List-Archive: List-Post: --envbJBWh7q8WU6mo Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Nov 21, 2003 at 06:00:09PM +0200, Michael Shigorin wrote: >>>> Как раз при работе над проектом не только фултаймеров и есть >>>> смысл использовать такой метод. Барьер в N дней и K подписей > ^^^^^^ >>> причем увеличение формального барьера на нем сильно >> Зачем барьер? > Гм. Упс. Мы имеем в виду разные барьеры -- одно дело барьер, ограничивающий попадение пакета вообще в сизиф (а чем sisyphus_check не такой барьер?), другое дело барьер, предназначеный для того, чтобы на машины конечных пользователей данного пакета попадал только оттестированый пакет. >> Есть Сизиф, который изначально динамичен (политкорректное >> название нестабильности). Возможно есть смысл создать ещё один >> репозиторий, в которые и переносить автоматом пакеты. > testing? ;-) Да. За исключением идеи с тем, что у разных пакетов могут быть разные периоды тестирования, и тем, что этот период будет зависеть от того, сколько человек (и какого ранга) подписали пакет. Скажем подпись человека из security team должна означать то, что пакет лучше всего перенести немедленно. >> Соответственно дистрибутвы формировать уже не на основе Сизифа, >> а на основе этого оттестированого репозитария, в который в >> принципе не может попасть непровереный пакет. > Насколько я понимаю, в него превращают Сизифа перед выпусками. > Этакий себе Big Sisyphus Lock, который становится все > неприемлемей при увеличении кол-ва майнтейнеров, выпускателей > дистрибутивов и этих самых дистрибутивов в единицу времени. > Форканье всего -- осмысленно разве что перед "большим релизом"... > и вообще слишком сильно завязано на внутренние процессы > подготовки релиза в конкретно взятой фирме. Почему, если для предлагаемой мною модели форка практически не требуется человеческих ресурсов? > (почему об этом говорю? -- да потому, что это единственная > реальная на сейчас мотивация дополнительного репо) С моей точки зрения есть смысл в существовании постоянно развивающегося дистрибутива средней надёжности (средней, в смысле на ядерный реактор ставить не стоит). Линукс слишком быстро развивается, чтобы выход нового дистрибутива раз в год мог устроить. Поэтому постоянно изменяющийся репозиторий, генерирующийся _автоматически_ на базе Сизифа, IMHO, вполне имеет право на жизнь и свою, отнюдь не маленькую, аудиторию. > > >> Кроме того если пакет является более-менее критичным для > > >> системы, то у мантейнеров пакетов, которые зависят от этого > > >> пакета, должно быть время проверить совместимость этих > > >> пакетов друг с другом. > > > Нет. В таких местах такой базар не работает ни разу. > > > Работает -- команда с ответственным во главе. Чье решение > > > действительно является определяющим. > > Ты действительно не согласен с тем, что у мантейнеров пакетов, > > которые зависят от обновляемых должно быть время проверки на > > совместимость, перед тем как этот пакет отправится в > > репозиторий, используемый на реальных рабочих машинах (пусть и > > не серверах)? > Это было бы слишком хорошо. Я не вижу, как это *реально* > сделать :( Реально сделать так, чтобы у них _было время_. Воспользуются они этим или нет -- другой вопрос. >> Как ты себе представляешь структуру такой команды? Один >> ответственный перепроверяет _все_ пакеты идущие в incoming. > Или не проверяет... Так может лучше модель, когда любой человек может проверить пакет, и если некоторое количество людей утверждают что пакет стабильный, то считать его стабильным? Модель очень напоминающая модель проверки достоверности PGP-ключа. -- С уважением, Денис http://dimline.ru/ --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vonp9yLOUeHSdCYRAqZzAKDO5eNZf6v948pFCXadviGA678jgQCfcILR A09RP2yCV8HiyHa5qlsSf3A= =cFUX -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo--