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: ran{}ran.pp.ru 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/
На 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/
15.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Убунту мало что решает, последний релиз 7.10 это прекрасно продемонстрировал. Я успел вдоволь наплеваться, пока настраивал и устанавливал эту систему своим знакомым (по их просьбе). Имеется другой, более положительный опыт. Но в моём случае народ был готов поковыряться. Ага, и менять по каждому чиху список стабильных пакетов. Какая же стабильность получится? По каждому чиху это делать не обязательно. После каждого релиза - можно. Если между релизами останется промежуток в пару лет, то обязательно найдутся люди, которым опять не хватит частоты обновления какого-нибудь пакета в stable. Может какая проблема с фризом и есть. Точнее с исправлением RC ошибок. Это я и хочу уяснить для себя. Куча ошибок после фриза -- это не баг -- это фича. :) Но менять из-за этого то, за что, фактически, и любят Debian, мне кажется не стоит. Вера, Любовь и Надежда - три вечных спутницы дебианщика ;) И они тоже. -- Regards, Yuri Kozlov
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/
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/
14.12.07, Stanislav Maslovski[EMAIL PROTECTED] написал(а): Потому и нужно произвести деление дистрибутива на (грубо говоря) системный софт + библиотеки и десктопный софт + тулкиты и отказаться от глобального фриза. Получился бы и не вариант убунты, где нестабильно всё подряд, и не текущий вариант, где stable == static. Что это даст? Какую проблему решит? -- Regards, Yuri Kozlov
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/
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: ran{}ran.pp.ru 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/
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/
У ср, 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 at 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-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 at 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 у 19:36 +0300, Stanislav Maslovski пише: Что все-таки означает, по-вашему, синяя линяя на сабжевом графике? Переводить не надо, читать умею, прошу пояснить. Баги у которых Version совпадает с тем, что в stable? -- Alexander Vlasov ZULU-UANIC JID: zulu at 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
