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

Вс Ноя 23 09:44:27 MSK 2003

On Sat, Nov 22, 2003 at 08:47:40AM +0200, Michael Shigorin wrote:

 >> -- одно дело барьер, ограничивающий попадение пакета вообще в
 >> сизиф (а чем sisyphus_check не такой барьер?), другое дело
 >> барьер, предназначеный для того, чтобы на машины конечных
 >> пользователей данного пакета попадал только оттестированый
 >> пакет.
 > Понимаю.  Но сказанное относилось к ним обоим.

Мне кажется, что огранчения первого типа могут вызывать какие-то
неприятности (если они неразумные), а второго типа -- вряд ли. 

 > >  >> Есть Сизиф, который изначально динамичен (политкорректное
 > >  >> название нестабильности). Возможно есть смысл создать ещё один
 > >  >> репозиторий, в которые и переносить автоматом пакеты.
 > >  > testing? ;-)
 > > Да. За исключением идеи с тем, что у разных пакетов могут быть
 > > разные периоды тестирования, и тем, что этот период будет
 > > зависеть от того, сколько человек (и какого ранга) подписали
 > > пакет. Скажем подпись человека из security team должна означать
 > > то, что пакет лучше всего перенести немедленно.
 > Вот и появилось слово "ранг".  Чем же он определяется?

Для некоторых пакетов (openssh, pam, tcb, glibc, login) он искуственный,
и задаётся ручками, скорее всего security командой. Для всех остальных его
можно рассчитывать. По поводу того какая формула даст пригодный
практически результат ещё стоит подумать, но базироваться рассчёт должен
на:
 - количестве прямо зависимых пакетов (и их ранге?)
 - количестве косвенно зависимых пакетов (и их ранге?)
 - группе, к которой относится пакет (скажем если он из группы Games, то
   требовать для него месяц тестирования или десяток подписей по меньшей
   времени неразумно).

 > (собственно, нечто вроде freshmeat/slashdot-like системы давно
 > напрашивается применительно к _пакетам_)

Я не знаком с этой системой.

 >>> Форканье всего -- осмысленно разве что перед "большим релизом"...
 >>> и вообще слишком сильно завязано на внутренние процессы
 >>> подготовки релиза в конкретно взятой фирме.
 >> Почему, если для предлагаемой мною модели форка практически не
 >> требуется человеческих ресурсов?
 > Sure? (я могу чего-то не понимать, но и setup time (написание
 > кода для переноса, инициализация этих самых рангов, ...), и
 > runtime (подписи, проверка, перекладывание?) -- в т.ч. и
 > человекоемкие вещи.

1. написание кода -- да, это некие ресурсы, если в ходе обсуждения мы
сможем чётко сформулировать ТЗ, то, _возможно_, я это напишу
(руководствуясь основным принципом Open Source -- тебе нужно, ты и пиши).

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

3. подписи -- один скриптик, и для человека сделать и отправить подпись
будет задачей на несколько секунд.

4. проверка -- дык если мне пакет _нужен_, то я с удовольствием его
проверю (особенно если у меня из репозитария какая-нибудь машина автоматом
апгрейдится :) А смысл этой проверки -- просто сказать "да, _меня_ этот
пакет устраивает".

5. перекладывание -- машина железная, пусть она и перекладывает,
единственная сложность при этом это поддержка целостности дистрибутива,
только по этому скрипт перекладывания будет требовать подумать, прежде чем
его написать.

Вывод: человекоёмким будет только создание этой системы, с учётом пользы,
которую это принесёт, такие затраты вполне оправданы.

 >>> (почему об этом говорю? -- да потому, что это единственная
 >>> реальная на сейчас мотивация дополнительного репо)
 >> С моей точки зрения есть смысл в существовании постоянно
 >> развивающегося дистрибутива средней надёжности (средней, в
 >> смысле на ядерный реактор ставить не стоит). Линукс слишком
 >> быстро развивается, чтобы выход нового дистрибутива раз в год
 >> мог устроить.
 > Почему?  Вон корпоративным пользователям (заметь: деньги они
 > платят, а не пользователи unstable) более удобен цикл порядка
 > трех лет.  С поддержкой продукта в течении.

Добавлю к своей реплике -- "... чтобы мог устроить _всех_".

 >> Поэтому постоянно изменяющийся репозиторий, генерирующийся
 >> _автоматически_ на базе Сизифа, IMHO, вполне имеет право на
 >> жизнь и свою, отнюдь не маленькую, аудиторию.
 > Да кристально понятно.  Я бы на таком и серверы некоторые держал
 > :-)

:)

 > Только это фактически постоянно выпускаемый дистрибутив (навроде
 > Compact, только объемами побольше) -- соответственно ему нужен
 > QA.

Позиционироваться он должен точно так же как и Сизиф -- репозиторий для
разработчика. Некоторый QA и будет выполняться теми, кто тестирует
интересные ему пакеты, с помощью пары скриптов (один отсылает подпись,
другой смотря на подписи и на даты выполняет перемещение).

 > Понятно, что некоторые вещи вроде "чистой BTS" могут быть
 > формальными критериями для скрипта -- только ситуации вроде
 > критических багов, правящихся наживую и попросту не попадающих в
 > BTS -- не отработаются.  Лекарство от этого -- обязать проводить
 > их _через_ багтрекер, но тут мне не нравится слово "обязать".
 > Потому что смотря кого.

Я не пытаюсь изобрести серебрянную пулю, которая позволит попрыгав с
бубном и написав скрипт автоматически получить дистрибутив, пригодный к
использованию в управлении ядерными реакторами. Боже упаси. У излагаю своё
предложение, которое может помочь _заметно улучшить_ качество
_общедоступного постоянно изменяющегося репозитария_.

Что-то не пройдёт через BTS, может быть какая-то ошибка не будет
исправлена, и с какой-то вероятностью таки попадёт кривующий пакет в этот
дистрибутив. В текущей схеме он попадёт туда 100%, в предлагаемой мною у
него будет масса заслонов.

 > >  > > Ты действительно не согласен с тем, что у мантейнеров пакетов,
 > >  > > которые зависят от обновляемых должно быть время проверки на
 > >  > > совместимость, перед тем как этот пакет отправится в
 > >  > > репозиторий, используемый на реальных рабочих машинах (пусть и
 > >  > > не серверах)?
 > >  > Это было бы слишком хорошо.  Я не вижу, как это *реально*
 > >  > сделать :(
 > > Реально сделать так, чтобы у них _было время_.
 > В такой формулировке это фултайм, period.

Причём тут фуллтайм? Лично я (по крайней мере в ближайшее время) не
собираюсь заниматься уделять времени работе в команде хотя бы сравнимое с
фуллтайм. При этом я очень хочу, чтобы критичные для меня пакеты попадали
ко мне на тестирование _до_ того, как они попадут в репозиторий, с
которого мне, возможно, в какой-то момент придётся обновиться. И время на
тестировании пары нужных мне пакетиков я найду.

 > Личное время -- как домашний каталог: можешь попробовать
 > ненавязчиво помочь человеку, сделав что-то за него (~/tmp и
 > TMPDIR), а можешь и возмутить его (~/Desktop и ~/Documents,
 > которые вечно сносятся и порой пытаются появиться).

Дык о чём и речь -- должна быть _возможность_ (например сделать mkdir
~/Desktop).

Я не слишком чётко, видимо, сформулировал идею -- речь шла _и_ о временном
барьере, _и_ о барьере с подписями. При этом временной барьер должен
уменьшаться в зависимости от числа подписей. И, возможно, отдельно должны
обрабатываться такие случаи как подписи security team (это повод для
немедленного переноса).

 > >  >> Как ты себе представляешь структуру такой команды? Один
 > >  >> ответственный перепроверяет _все_ пакеты идущие в incoming.
 > >  > Или не проверяет...
 > > Так может лучше модель, когда любой человек может проверить
 > > пакет, и если некоторое количество людей утверждают что пакет
 > > стабильный, то считать его стабильным? Модель очень
 > > напоминающая модель проверки достоверности PGP-ключа.
 > Здесь ключ -- "может проверить".
 > 1) это QA => ответственность
 > 2) это тоже риск
 > 3) где грань, когда человек _может_ сказать, что "пакет
 >    стабилен"? (применительно как к пакету, так и к человеку)

Абсолютно никакой ответственности. Человек просто говорит что "лично для
меня этот пакет пригоден к использованию и лично я считаю этот пакет
пригодным для установки на свои машины". Говорит он это с чисто
эгоистической позиции.

Фишка в том, что если посмотрит несколько человек, то заметно больше
шансов что block bug будет найден до переноса в другой репозитарий.
Собственно и городится всё это исключительно для этой цели.

Риск -- да, конечно. На текущий момент использование большинства программ,
входящих в состав дистрибутива (начиная с ядра) является риском. И будет
являться до тех пор, пока не будут использоваться более другие языки
программирования чем C/C++, и не начнут использоваться механизмы доказания
программ. Однако мой идеализм не заходит настолько далеко, чтобы из-за
этого не пользоваться линуксом :)

Для меня на домашней машине после реализации такого механизма будет вполне
разумным ставить a[t-get upgrade -y в cron'e. Ты даже на некоторые сервера
уже готов такую систему поставить. А кто-то принципиально не станет
ставить нечто, неоттестированое лет эдак много. У каждого своя оценка
риска.

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

-- 
С уважением, Денис

http://freesource.info

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20031123/4e2052ec/attachment-0001.bin>