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

Michael Shigorin =?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Пт Ноя 21 19:00:09 MSK 2003


On Thu, Nov 20, 2003 at 08:33:26PM +0300, Денис Смирнов wrote:
>  > > Как раз при работе над проектом не только фултаймеров и есть
>  > > смысл использовать такой метод. Барьер в N дней и K подписей
                                       ^^^^^^
>  > причем увеличение формального барьера на нем сильно
> Зачем барьер?

Гм.

> Есть Сизиф, который изначально динамичен (политкорректное
> название нестабильности). Возможно есть смысл создать ещё один
> репозиторий, в которые и переносить автоматом пакеты.

testing? ;-)

> Соответственно дистрибутвы формировать уже не на основе Сизифа,
> а на основе этого оттестированого репозитария, в который в
> принципе не может попасть непровереный пакет.

Насколько я понимаю, в него превращают Сизифа перед выпусками.
Этакий себе Big Sisyphus Lock, который становится все
неприемлемей при увеличении кол-ва майнтейнеров, выпускателей
дистрибутивов и этих самых дистрибутивов в единицу времени.

Форканье всего -- осмысленно разве что перед "большим релизом"...
и вообще слишком сильно завязано на внутренние процессы
подготовки релиза в конкретно взятой фирме.

(почему об этом говорю? -- да потому, что это единственная
реальная на сейчас мотивация дополнительного репо)

>  >> Кроме того если пакет является более-менее критичным для
>  >> системы, то у мантейнеров пакетов, которые зависят от этого
>  >> пакета, должно быть время проверить совместимость этих
>  >> пакетов друг с другом.
>  > Нет.  В таких местах такой базар не работает ни разу.
>  > Работает -- команда с ответственным во главе.  Чье решение
>  > действительно является определяющим.
> Ты действительно не согласен с тем, что у мантейнеров пакетов,
> которые зависят от обновляемых должно быть время проверки на
> совместимость, перед тем как этот пакет отправится в
> репозиторий, используемый на реальных рабочих машинах (пусть и
> не серверах)?

Это было бы слишком хорошо.  Я не вижу, как это *реально*
сделать :(

> Как ты себе представляешь структуру такой команды? Один
> ответственный перепроверяет _все_ пакеты идущие в incoming.

Или не проверяет...

On Fri, Nov 21, 2003 at 07:42:59AM +0200, Denis Ovsienko wrote:
> > Зачем барьер? Есть Сизиф, который изначально динамичен
> > (политкорректное название нестабильности). Возможно есть
> > смысл создать ещё один репозиторий, в которые и переносить
> > автоматом пакеты. Соответственно
> А потом ещё один, и туда --- ещё более надёжные... :) Уже есть
> Daedalus, только мы им по назначению почему-то не пользуемся.

На самом деле да.

Поддерживаемые пакеты обладают некоторым "кредитом доверия" на
предмет проверки.  Те, на которых не хочется его подрывать --
идут в Daedalus.

Например, в xmms-1.2.8 вылез какой-то странный ляп, 

> > дистрибутвы формировать уже не на основе Сизифа, а на основе
> > этого оттестированого репозитария, в который в принципе не
> > может попасть непровереный пакет.
> В любой дистрибутив в принципе может попасть непроверенный
> пакет независимо ни от чего.  Самоконтроль м самодисциплину
> никакой командой проверяющих не заменишь, на собственном опыте
> убеждался не раз.

Именно.

> А всякие рассылки типа sisyphus-daily & cvsdiff-daily не нужны.

Видишь ли... --changes-since предыдущий_в_сизифе плюс spec.diff в
аттаче -- то, чего хочется довольно давно.  Собирался себе
сделать было.

> Нужны комментарии своих действий devel@ при заливке очередной
> сборки.

Только нетривиальных, потому как иначе -- дублирование ченжлога и
ухудшение SNR.  Рассылки появляются по мере роста специфичных тем
узкого профиля и выделенной направленности, понимаешь ли :)

-- 
 ---- 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/20031121/dbf568ac/attachment-0001.bin>


Подробная информация о списке рассылки Devel