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

[Michael Shigorin]

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 <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/62bc62aa/attachment-0001.bin>