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

[Michael Shigorin <mike@osdn.org.ua>]

[-- Attachment #1: Type: text/plain, Size: 8685 bytes --]

On Sun, Nov 23, 2003 at 09:44:27AM +0300, Денис Смирнов wrote:
>  >> сизиф (а чем sisyphus_check не такой барьер?), другое дело
>  >> барьер, предназначеный для того, чтобы на машины конечных
>  >> пользователей данного пакета попадал только оттестированый
>  >> пакет.
>  > Понимаю.  Но сказанное относилось к ним обоим.
> Мне кажется, что огранчения первого типа могут вызывать какие-то
> неприятности (если они неразумные), а второго типа -- вряд ли. 

Да; проблема в том, что (на сейчас) первое автоматизируется,
второе -- непонятно как (с тем чтоб реально, а не схема, которая
будет великолепна и никем не используема).

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

Вот.  Мне в голову что-то подобное тоже приходило, но у Вас
получилось сформулировать.

(на самом деле это добавляет в разработку sisyphus еще один
спортивно-соревновательный момент :))

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

Схожая шкала с влиянием оценки на ранг, зависящей от ранга
оценивающего (в т.ч.), если правильно понял (в случае /.).

Мы тут подумывали сделать нечто вроде community site с
возможностью публикации резюмов и проделанных работ _и_ вот такой
вот оценки, чтобы профессиональный журнал человека мог быть
оценен и сравнен при принятии решения о взятии его на работу.

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

Эт хорошо.

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

Скорее соглашусь.

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

Ну положим.

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

Это понятно.  Тут просто наблюдается хроническая нехватка
ресурсов на автоматизацию из-за недостатка этой самой
автоматизации...

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

Так не бывает.  См. в т.ч. RH -- это _очень_ хороший пример.
Их Федоре вон теперь расти до Sisyphus :)

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

Да прекрасно понятно :-)  И мне оно нравится, почему же и
докапываюсь везде, где могу. (где могут вылезти бяки, которые
лучше продумать до -- в разумных пределах)

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

Что-то не слышно мнения QA, кстати.  Удивительно.

>  > > Реально сделать так, чтобы у них _было время_.
>  > В такой формулировке это фултайм, period.
> Причём тут фуллтайм?

Ну, "_было_" == гарантия.  Другое дело, что время, выделяемое
человеком, но сэкономленное от всякой ерунды (вроде выделения
мышом в xterm пачки пакетов, порожденных hasher, и переноса в
подписное отделение и отправки) -- может действительно
применяться на более полезные дела.

>  > Личное время -- как домашний каталог: можешь попробовать
>  > ненавязчиво помочь человеку, сделав что-то за него
> Дык о чём и речь -- должна быть _возможность_

ACK

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

Есть подозрение, что security team все равно переносит чуть ли не
руками... но ладно.

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

Если формулировку закрепить для несоздания иллюзий -- согласен.

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

Это понятно.  Я беспокоюсь о том, чтобы этих несколько человек
*нашлось*... впрочем, может, вижу проблемы там, где их нет.

> Однако мой идеализм не заходит настолько далеко, чтобы из-за
> этого не пользоваться линуксом :)

:)

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

IMCO главное тут -- не домашние пользователи, не в обиду им будь
сказано.  А именно разработчики, которые путем расширения ареала
таких систем могут, с одной стороны, обеспечить себе большее
удобство (стал бы я портировать пакеты назад на Мастер), а с
другой стороны -- обеспечивать все то же дополнительное
тестирование уже на уровне перехода testing-->stable.

Домашним пользователям же, как правило, достаточно stable (плохо
разве то, что у нас два года нет stable без выдающихся мелких
ляпов, но это вроде как исправляется -- compact-20031026_mike
меня в своем роде устраивает); те же, кому недостаточно -- или
уже разработчики, или очень быстро ими становятся по вполне
понятным причинам.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]