Re: вопрос по http://bugs.debian.org/release-critical/
15.12.07, Stanislav Maslovski<[EMAIL PROTECTED]> написал(а): > > Если между релизами останется промежуток в пару лет, то обязательно > > найдутся люди, которым опять не хватит частоты обновления > > какого-нибудь пакета в stable. > > Во-порвых, их будет меньше. При правильно выбранном критерии - значительно > меньше. Во-вторых, им будет, что ответить. На данный момент ответы сводятся > к иррациональному "только не трогайте, нам и так хорошо." На самом деле, действительно неплохо. :) А ответите Вы им в стиле "согласно статистической температуре по больнице пакет не может покинуть stable". Чем это лучше. Что есть некие цифры? Ваш вариант -- это такая же проба решить некоторую проблему как и тот, что уже работает. Не факт, что он окажется лучше имеющегося. За исключением того, что да, цифры RC будут ниже за счёт простого _уменьшения_ количества стабилизируемых пакетов. > > > > > > Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. > > > > > > Это я и хочу уяснить для себя. > > > > Куча ошибок после фриза -- это не баг -- это фича. :) > > На мой взгдяд, разумнее было бы проанализировать, почему это так. Свои > предположения я высказал, возможные варианты действий - тоже обозначил. > Интересно было бы выслушать еще чьи-то идеи/мысли (ессно, кроме тех, что > "настоящему индейцу завсегда везде ништяк"). Тогда я бы начал с просмотра программы, которая строит этот график. И поискал бы, из чего сложилась такая вертикальная линия в июнe. -- Regards, Yuri Kozlov
Re: вопрос по http://bugs.debian.org/release-critical/
15.12.07, Stanislav Maslovski<[EMAIL PROTECTED]> написал(а): > Убунту мало что решает, последний релиз 7.10 это прекрасно > продемонстрировал. Я успел вдоволь наплеваться, пока настраивал и > устанавливал эту систему своим знакомым (по их просьбе). Имеется другой, более положительный опыт. Но в моём случае народ был готов поковыряться. > > Ага, и менять по каждому чиху список стабильных пакетов. > > Какая же стабильность получится? > > По каждому чиху это делать не обязательно. После каждого релиза - можно. Если между релизами останется промежуток в пару лет, то обязательно найдутся люди, которым опять не хватит частоты обновления какого-нибудь пакета в stable. > > Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. > > Это я и хочу уяснить для себя. Куча ошибок после фриза -- это не баг -- это фича. :) > > Но менять из-за этого то, за что, фактически, и любят Debian, > > мне кажется не стоит. > > Вера, Любовь и Надежда - три вечных спутницы дебианщика ;) И они тоже. -- Regards, Yuri Kozlov
Re: вопрос по http://bugs.debian.org/release-critical/
На Sat, 15 Dec 2007 09:08:04 +0300 "Yuri Kozlov" <[EMAIL PROTECTED]> записано: > Если кого-то не устраивает скорость фиксации проблем с > безопасностью в stable то, наверное, стоит перейти на платный > дистрибутив. Странное утверждение. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail: [EMAIL PROTECTED] Homepage: http://gq.net.ru signature.asc Description: PGP signature
Re: вопрос по http://bugs.debian.org/release-critical/
Stanislav Maslovski -> debian-russian@lists.debian.org @ Sat, 15 Dec 2007 11:24:58 +0300: >> >> > Потому и нужно произвести деление дистрибутива на (грубо говоря) >> >> > системный софт + библиотеки и десктопный софт + тулкиты и отказаться >> >> > от глобального фриза. Получился бы и не вариант убунты, где >> нестабильно >> >> > всё подряд, и не текущий вариант, где stable == static. >> >> >> >> Что это даст? Какую проблему решит? >> >> SM> Это удовлетворит как сисадминов, которым достаточно базовой системы >> SM> с набором сервисов, так и пользователей прикладного софта, который >> SM> фиксится, как правило, быстрее в апстриме, чем усилиями >> SM> сопровождающего. >> >> Ну, вообще-то такое деление уже есть. Есть stable, который можно >> апгрейдить без страха, и есть testing, который достаточно свеж и может >> ставиться на некритичные к "если что" машины. SM> Мы так будем ходить по кругу. Повторюсь, что при сегодняшней SM> практике длительных фризов, в тестинге периодически наступает "час SM> Х", когда ломается многое и сразу. Да, но этот час X обычно происходит в тот момент, когда недавно вышел stable. И если завести себе привычку переходить на новый testing не сразу, а через месяц-два хотя бы после выхода stable, то все будет совсем не так страшно. SM> Тестинг - это не более чем сгенерированный скриптами задержанный SM> срез анстейбла, с некоторыми ограничениями на самые очевидные баги SM> пакетирования. А поскольку на неочевидные баги ты наткнешься не сразу и с достаточно небольшой вероятностью в числе первых, то на нем вполне можно жить. >> Делить же основной дистрибутив на "системный" и "десктопный" смысла не >> видно, ибо "десктопные" приблуды и десктопное железо все чаще норовят >> захотеть ядро посвежее и соответствующие околоядерные софты. Каковые >> ядро и софты - самые что ни на есть системные, системнее не бывает. SM> Это не аргумент, ибо ничто не мешает иметь в дистрибутиве две (или SM> более) версии ядер и настроить зависимости нужным образом. То есть, как следствие, две или более версий системного софта. И добиваться, чтобы они уживались надлежащим образом при старте системы - в частности, чтобы можно было безболезненно экспериментировать с новым ядром, имея возможность перезагрузиться со старым. Это очень отдельная развлекуха. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] /итд/почтопосылалка.нстрк (c) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
14.12.07, Stanislav Maslovski<[EMAIL PROTECTED]> написал(а): > On Fri, Dec 14, 2007 at 06:27:45PM +0300, Yuri Kozlov wrote: > > 14.12.07, Stanislav Maslovski<[EMAIL PROTECTED]> написал(а): > > > > > > Потому и нужно произвести деление дистрибутива на (грубо говоря) > > > системный софт + библиотеки и десктопный софт + тулкиты и отказаться > > > от глобального фриза. Получился бы и не вариант убунты, где нестабильно > > > всё подряд, и не текущий вариант, где stable == static. > > > > Что это даст? Какую проблему решит? > > Это удовлетворит как сисадминов, которым достаточно базовой системы с > набором сервисов, так и пользователей прикладного софта, который > фиксится, как правило, быстрее в апстриме, чем усилиями сопровождающего. > Как я понял, вы предлагаете оставить stable только для базовых пакетов. Но это уже есть? Получается, проблем с этим у сисадминов нет. Если кого-то не устраивает скорость фиксации проблем с безопасностью в stable то, наверное, стоит перейти на платный дистрибутив. Остаются неопытные пользователи. Если по каким-то причинам не устраивает стабильная ветка -- всегда есть Ubuntu, которая решает вопросы с новым софтом. И релиз раз в полгода. Чего ещё нужно? > Кстати, по поводу того, как делить. Надо подойти к задаче статистически и > связать в одну модель такие параметры, как: > > 1) важность пакета (например, оценить можно по числу зависящих от него, > рекурсивно, с весом, пропорциональным их собственной важности) > 2) частота выхода новых версий > 3) частота багрепортов > 4) частота исправлений > > Далее, сформировать некий критерий и по его значению поделить. Периодически > пересчитывать критерий и корректировать списки пакетов. Ага, и менять по каждому чиху список стабильных пакетов. Какая же стабильность получится? Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. Но менять из-за этого то, за что, фактически, и любят Debian, мне кажется не стоит. -- Regards, Yuri Kozlov
Re: вопрос по http://bugs.debian.org/release-critical/
Stanislav Maslovski -> debian-russian@lists.debian.org @ Fri, 14 Dec 2007 23:12:31 +0300: >> > Потому и нужно произвести деление дистрибутива на (грубо говоря) >> > системный софт + библиотеки и десктопный софт + тулкиты и отказаться >> > от глобального фриза. Получился бы и не вариант убунты, где нестабильно >> > всё подряд, и не текущий вариант, где stable == static. >> >> Что это даст? Какую проблему решит? SM> Это удовлетворит как сисадминов, которым достаточно базовой системы SM> с набором сервисов, так и пользователей прикладного софта, который SM> фиксится, как правило, быстрее в апстриме, чем усилиями SM> сопровождающего. Ну, вообще-то такое деление уже есть. Есть stable, который можно апгрейдить без страха, и есть testing, который достаточно свеж и может ставиться на некритичные к "если что" машины. Делить же основной дистрибутив на "системный" и "десктопный" смысла не видно, ибо "десктопные" приблуды и десктопное железо все чаще норовят захотеть ядро посвежее и соответствующие околоядерные софты. Каковые ядро и софты - самые что ни на есть системные, системнее не бывает. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Вам правду резать или кусочком? Кнышев -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
> Из обсуждаемых графиков видно, что скорость отлова RC багов после релиза > Etch оказалась заметно выше, чем это происходило в течение фриза. Huh? Etch был выпущен 8 апреля. Непосредственно после этого момента графики РЕЗКО идут вверх. То есть, etch был выпущен без известных на тот момент RC багов (плюс-минус некоторые детали). После этого было обнаружено некоторое количество новых багов - это естественный процесс. В случае выпуска релиза без freeze, в релизе уже на момент его выпуска было N серьёзных багов. А новые баги, обнаруженные с этого момента, к этим N бы добавлялись. То есть ситуация была бы хуже ровно настолько, сколько в среднем открыто багов на момент, когда нет фриза. > Потому и нужно произвести деление дистрибутива на (грубо говоря) > системный софт + библиотеки и десктопный софт + тулкиты и отказаться > от глобального фриза. Получился бы и не вариант убунты, где нестабильно > всё подряд, и не текущий вариант, где stable == static. Стабильность (в смысле неизменчивость) разным людям нужна в разных частях дистрибутива. Деление, удовлетворяющее всех, невозможно. Текущая ситуация (stable + минимум backports) кажется правильнее. Каждый может поставить именно ту свежатинку, которая именно ему нужна. А нужна она не так уж и часто (я имею в виду нужна для конкретной цели, а не ддля удовлетворения жажды новых версий). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
14.12.07, Stanislav Maslovski<[EMAIL PROTECTED]> написал(а): > > Потому и нужно произвести деление дистрибутива на (грубо говоря) > системный софт + библиотеки и десктопный софт + тулкиты и отказаться > от глобального фриза. Получился бы и не вариант убунты, где нестабильно > всё подряд, и не текущий вариант, где stable == static. Что это даст? Какую проблему решит? -- Regards, Yuri Kozlov
Re: вопрос по http://bugs.debian.org/release-critical/
Stanislav Maslovski wrote: > On Thu, Dec 13, 2007 at 09:47:37PM +0200, Oleg Gashev wrote: >> Приветствую, >> >> Stanislav Maslovski wrote: >>> >>> И как же Вы пользуясь своей гипотезой объясните линейный рост числа >>> багов в промежутке между 01.07.2007 и текущим датой на 400 единиц? >>> Очевидно, что не в старых багах дело. >>> >> >> >> Покажите мне софт, в котором нету багов. >> >> P.S. То, что есть баги, это очень хорошо. Они должны быть. Плохо, когда >> их нет. > > Все верно, и это только подтверждает мой исходный тезис. "Стабильный" в случае дебиана значит в первую очередь "не меняющийся", а вовсе не лишённый багов. Софта без багов не бывает. С этим ничего не сделаешь. А тогда (по крайней мере в некоторых контекстах) заметно проще, если баги остаются те же, и соответственно и способы их обхода тоже те же. Если используемый на сервере дистрибутив менять, скажем, раз в несколько месяцев (или, не дай бог, всякий раз когда testing обновляется) - то ровно с такой же периодичностью придётся встречать новый комплект багов и как-то решать проблемы, из-за этих багов возникающие. Вместо того, чтобы заниматься делом. Большое спасибо политике debian, из-за которой мне приходится этим заниматься реже. P.S. Использую сервера и десктопы на etch. Полёт нормальный. P.P.S. Почему-то так вышло, что использовать десктопы на testing/unstable я прекратил примерно тогда же, когда стало по-настоящему много работы. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
У чт, 2007-12-13 у 22:26 +0300, Stanislav Maslovski пише: > On Thu, Dec 13, 2007 at 11:59:42AM +0200, Alexander Vlasov wrote: > > У ср, 2007-12-12 у 21:04 +0300, Stanislav Maslovski пише: > > > On Wed, Dec 12, 2007 at 06:50:57PM +0200, Alexander Vlasov wrote: > > > > У ср, 2007-12-12 у 19:36 +0300, Stanislav Maslovski пише: > > > > > Что все-таки означает, по-вашему, синяя линяя на сабжевом графике? > > > > > Переводить не надо, читать умею, прошу пояснить. > > > > > > > > Баги у которых Version совпадает с тем, что в stable? > > > > > > Угу, совпадает с моим пониманием. Интересно, что синия линия уже успела > > > практически слиться с зеленой. Если она действительно показывает RC баги, > > > не выявленные за период фриза, мы с вами имеем хорошую иллюстрацию того, > > > что текущая политика релизов - это именно политика. > > > > > > PS я не издеваюсь, я пытаюсь анализировать. > > > > Тогда стоит заглянуть в баглист любого большого пакета. > > Там хватает багов N-летней давности, которые так и не отмечены > > "закрытыми". И не факт что эти баги присутствуют до сих пор. > > И как же Вы пользуясь своей гипотезой объясните линейный рост числа багов в > промежутке между 01.07.2007 и текущим датой на 400 единиц? Очевидно, что не в > старых багах дело. Никак. Очевидно она (гипотеза) не объясняет полностью эту кривую. -- Alexander Vlasov ZULU-UANIC JID: zulu jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
У ср, 2007-12-12 у 21:04 +0300, Stanislav Maslovski пише: > On Wed, Dec 12, 2007 at 06:50:57PM +0200, Alexander Vlasov wrote: > > У ср, 2007-12-12 у 19:36 +0300, Stanislav Maslovski пише: > > > Что все-таки означает, по-вашему, синяя линяя на сабжевом графике? > > > Переводить не надо, читать умею, прошу пояснить. > > > > Баги у которых Version совпадает с тем, что в stable? > > Угу, совпадает с моим пониманием. Интересно, что синия линия уже успела > практически слиться с зеленой. Если она действительно показывает RC баги, > не выявленные за период фриза, мы с вами имеем хорошую иллюстрацию того, > что текущая политика релизов - это именно политика. > > PS я не издеваюсь, я пытаюсь анализировать. Тогда стоит заглянуть в баглист любого большого пакета. Там хватает багов N-летней давности, которые так и не отмечены "закрытыми". И не факт что эти баги присутствуют до сих пор. -- Alexander Vlasov ZULU-UANIC JID: zulu jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: вопрос по http://bugs.debian.org/release-critical/
На Wed, 12 Dec 2007 21:04:52 +0300 Stanislav Maslovski <[EMAIL PROTECTED]> записано: > On Wed, Dec 12, 2007 at 06:50:57PM +0200, Alexander Vlasov wrote: > > У ср, 2007-12-12 у 19:36 +0300, Stanislav Maslovski пише: > > > Что все-таки означает, по-вашему, синяя линяя на сабжевом графике? > > > Переводить не надо, читать умею, прошу пояснить. > > > > Баги у которых Version совпадает с тем, что в stable? > > Угу, совпадает с моим пониманием. Интересно, что синия линия уже > успела практически слиться с зеленой. Если она действительно > показывает RC баги, не выявленные за период фриза, мы с вами имеем > хорошую иллюстрацию того, что текущая политика релизов - это именно > политика. > > PS я не издеваюсь, я пытаюсь анализировать. Видишь посередине спад в синем графике? Это выпуск 4.0r1. Там же в синюю линию попадают все секьюрити баги. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail: [EMAIL PROTECTED] Homepage: http://gq.net.ru signature.asc Description: PGP signature
Re: вопрос по http://bugs.debian.org/release-critical/
У ср, 2007-12-12 у 19:36 +0300, Stanislav Maslovski пише: > Что все-таки означает, по-вашему, синяя линяя на сабжевом графике? > Переводить не надо, читать умею, прошу пояснить. Баги у которых Version совпадает с тем, что в stable? -- Alexander Vlasov ZULU-UANIC JID: zulu jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]