[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