[devel] Надёжность Sisyphus

[Денис Смирнов]

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/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20031122/9f1d8885/attachment-0001.bin>