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