From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 24 Nov 2003 14:21:17 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?B?7sHEo9bOz9PU?= =?koi8-r?Q?=D8?= Sisyphus Message-ID: <20031124112117.GA9800@localhost.localdomain> References: <20031114152146.GB29311@localhost.localdomain> <20031117083502.GA18832@osdn.org.ua> <20031117212959.GC30633@localhost.localdomain> <20031120145103.GF9136@osdn.org.ua> <20031120173326.GE7822@localhost.localdomain> <20031121160009.GL9136@osdn.org.ua> <20031121215554.GA5696@localhost.localdomain> <20031122064740.GW9136@osdn.org.ua> <20031123064427.GA15250@localhost.localdomain> <20031124072744.GC10424@osdn.org.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20031124072744.GC10424@osdn.org.ua> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 11:21:24 -0000 Archived-At: List-Archive: List-Post: --huq684BweRXVnRxX Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/wems9yLOUeHSdCYRAozrAKCFn8ygVE8H7gU1OIZwAoOEp5MBBwCZAUIY IUyWaqjgD2ZuW7MQpHgwG3Y= =Pk/c -----END PGP SIGNATURE----- --huq684BweRXVnRxX--