From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 22 Nov 2003 08:47:40 +0200 From: Michael Shigorin To: ALT Devel discussion list Message-ID: <20031122064740.GW9136@osdn.org.ua> Mail-Followup-To: ALT Devel discussion list References: <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> <20031121215554.GA5696@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qo7zVO9a9OQ5oQtr" Content-Disposition: inline In-Reply-To: <20031121215554.GA5696@localhost.localdomain> User-Agent: Mutt/1.4.1i Subject: [devel] Re: =?koi8-r?b?7sHEo9bOz9PU2A==?= Sisyphus 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: Sat, 22 Nov 2003 06:47:43 -0000 Archived-At: List-Archive: List-Post: --qo7zVO9a9OQ5oQtr Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sat, Nov 22, 2003 at 12:55:54AM +0300, Денис Смирнов wrote: > >>>> Как раз при работе над проектом не только фултаймеров и есть > >>>> смысл использовать такой метод. Барьер в N дней и K подписей > > ^^^^^^ > >>> причем увеличение формального барьера на нем сильно > >> Зачем барьер? > > Гм. > Упс. Мы имеем в виду разные барьеры Да нет. > -- одно дело барьер, ограничивающий попадение пакета вообще в > сизиф (а чем sisyphus_check не такой барьер?), другое дело > барьер, предназначеный для того, чтобы на машины конечных > пользователей данного пакета попадал только оттестированый > пакет. Понимаю. Но сказанное относилось к ним обоим. > >> Есть Сизиф, который изначально динамичен (политкорректное > >> название нестабильности). Возможно есть смысл создать ещё один > >> репозиторий, в которые и переносить автоматом пакеты. > > testing? ;-) > Да. За исключением идеи с тем, что у разных пакетов могут быть > разные периоды тестирования, и тем, что этот период будет > зависеть от того, сколько человек (и какого ранга) подписали > пакет. Скажем подпись человека из security team должна означать > то, что пакет лучше всего перенести немедленно. Вот и появилось слово "ранг". Чем же он определяется? (собственно, нечто вроде freshmeat/slashdot-like системы давно напрашивается применительно к _пакетам_) > > Форканье всего -- осмысленно разве что перед "большим релизом"... > > и вообще слишком сильно завязано на внутренние процессы > > подготовки релиза в конкретно взятой фирме. > Почему, если для предлагаемой мною модели форка практически не > требуется человеческих ресурсов? Sure? (я могу чего-то не понимать, но и setup time (написание кода для переноса, инициализация этих самых рангов, ...), и runtime (подписи, проверка, перекладывание?) -- в т.ч. и человекоемкие вещи. > > (почему об этом говорю? -- да потому, что это единственная > > реальная на сейчас мотивация дополнительного репо) > С моей точки зрения есть смысл в существовании постоянно > развивающегося дистрибутива средней надёжности (средней, в > смысле на ядерный реактор ставить не стоит). Линукс слишком > быстро развивается, чтобы выход нового дистрибутива раз в год > мог устроить. Почему? Вон корпоративным пользователям (заметь: деньги они платят, а не пользователи unstable) более удобен цикл порядка трех лет. С поддержкой продукта в течении. > Поэтому постоянно изменяющийся репозиторий, генерирующийся > _автоматически_ на базе Сизифа, IMHO, вполне имеет право на > жизнь и свою, отнюдь не маленькую, аудиторию. Да кристально понятно. Я бы на таком и серверы некоторые держал :-) Только это фактически постоянно выпускаемый дистрибутив (навроде Compact, только объемами побольше) -- соответственно ему нужен QA. Понятно, что некоторые вещи вроде "чистой BTS" могут быть формальными критериями для скрипта -- только ситуации вроде критических багов, правящихся наживую и попросту не попадающих в BTS -- не отработаются. Лекарство от этого -- обязать проводить их _через_ багтрекер, но тут мне не нравится слово "обязать". Потому что смотря кого. > > > Ты действительно не согласен с тем, что у мантейнеров пакетов, > > > которые зависят от обновляемых должно быть время проверки на > > > совместимость, перед тем как этот пакет отправится в > > > репозиторий, используемый на реальных рабочих машинах (пусть и > > > не серверах)? > > Это было бы слишком хорошо. Я не вижу, как это *реально* > > сделать :( > Реально сделать так, чтобы у них _было время_. В такой формулировке это фултайм, period. Личное время -- как домашний каталог: можешь попробовать ненавязчиво помочь человеку, сделав что-то за него (~/tmp и TMPDIR), а можешь и возмутить его (~/Desktop и ~/Documents, которые вечно сносятся и порой пытаются появиться). > Воспользуются они этим или нет -- другой вопрос. За то, что автоматизация -- друг ленивого человека -- не спорю :-) > >> Как ты себе представляешь структуру такой команды? Один > >> ответственный перепроверяет _все_ пакеты идущие в incoming. > > Или не проверяет... > Так может лучше модель, когда любой человек может проверить > пакет, и если некоторое количество людей утверждают что пакет > стабильный, то считать его стабильным? Модель очень > напоминающая модель проверки достоверности PGP-ключа. Здесь ключ -- "может проверить". 1) это QA => ответственность 2) это тоже риск 3) где грань, когда человек _может_ сказать, что "пакет стабилен"? (применительно как к пакету, так и к человеку) -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ --qo7zVO9a9OQ5oQtr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/vwaMbsPDprYMm3IRAovQAJ0eZpbOav6/C2REeQWhpFH9n910jACfQr3Z hnIWaZmAvkA+CcqkylK37oE= =0uqJ -----END PGP SIGNATURE----- --qo7zVO9a9OQ5oQtr--