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

[Денис Смирнов]

On Mon, Nov 24, 2003 at 09:27:44AM +0200, Michael Shigorin wrote:

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

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

Об этом я не подумал. Интересная мысль. Тогда эту статистику в каком-то
виде надо публиковать.

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

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

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

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

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

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

Змкнутый круг. IMHO такой круг рвётся только тем, что задачи по
автоматизации на некоторое время выносятся на самый верх по приоритетам.

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

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

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


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

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

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

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

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

Именно, только при такой формулировке люди будут реально подписывать
пакеты. Иначе безответственные будут подписывать хаотичным образом, а
ответственные не будут подписывать вообще, прок будет минимальный (хотя
всё равно будет, то что block bug в BTS поставленый вовремя гарантирует
непрохождение пакета уже само по себе полезно).

Ещё мысль -- если висит block или critical bug на пакет, который уже в
протестированом репозитории, то прохождение новой версии этого пакета
должно ускоряться (вопрос только насколько).

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

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

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

 > Домашним пользователям же, как правило, достаточно stable 

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

Или не утруждают себя таким геморроем как использование Линукса. У меня в
одной комнате со мной есть отличным пример -- братец, у которого тоже
Мастер (я ему коробочку подарил). Так вот ему действительно оказалось
вполне комфортно в нём работать. Только вот неработа kppp из коробки (без
правки под рутом), то что apt в некоторых случаях при установке не
ставится (а rpm'ом он пользоваться не умеет), и мерзкий глюк с поддержкой
звука (то, что надо во-первых использовать OSS-драйвера, редактируя для
этого modules.conf, а во-вторых то, что надо убирать сортировку из
/etc/init.d/sound, ибо иначе первым оказывается тюнер) привели его к тому,
что он пользуется виндой даже тогда, когда ему удобнее линукс. Кстати он
весьма странный в этом смысле человек -- хоть и воспитывался уже на
Win'98, но тексты ему набивать нравится больше в Far'е на полный экран,
чем в ворде :)

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

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

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

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/20031124/5026129b/attachment-0001.bin>