Re: вопрос по http://bugs.debian.org/release-critical/
On Fri, Dec 14, 2007 at 06:18:54PM +0300, Nikita V. Youshchenko wrote:
> > Из обсуждаемых графиков видно, что скорость отлова RC багов после релиза
> > Etch оказалась заметно выше, чем это происходило в течение фриза.
>
> Huh?
>
> Etch был выпущен 8 апреля.
> Непосредственно после этого момента графики РЕЗКО идут вверх.
Вероятно, Вы про зеленую кривую. С ней все ясно и вопросов нет.
Синяя же кривая, которая показывает RC баги в stable, прыгает вверх в районе
июня 2007-го года. Я полагаю, что этот скачок надо рассматривать просто как
начальную точку отсчета, ведь раньше подобной статистики не велось.
На всякий случай поясню, что под "скоростью отлова" я подразумевал
"скорость выявления багов" т.е. частоту подачи багрепортов,
а не скорость их исправления. Может быть это вызвало Ваше Huh?
> То есть, etch был выпущен без известных на тот момент RC багов (плюс-минус
> некоторые детали).
Я в курсе.
> После этого было обнаружено некоторое количество новых
> багов - это естественный процесс.
Некоторое? 600 - 200 = 400 за примерно полгода, синяя кривая. И это RC баги
на версии пакетов в stable. Ведь не случайно же я поднял эту тему. Давайте
разберемся, что это за баги.
> В случае выпуска релиза без freeze, в релизе уже на момент его выпуска было
> N серьёзных багов. А новые баги, обнаруженные с этого момента, к этим N бы
> добавлялись. То есть ситуация была бы хуже ровно настолько, сколько в
> среднем открыто багов на момент, когда нет фриза.
Нет. С физической точки зрения, репорты и исправление багов -
динамический процесс. На мой взгляд, длительный фриз искусственно создает
ситуацию, когда скорость "репортинга" становится меньше скорости "фиксинга",
в результате чего, по прошествии полутора-двух лет, кривая-таки доходит до
нуля и наступает момент релиза. Каково же при этом количество скрытых,
неисправленных багов - на это нельзя дать простого ответа.
Почему мне и хочется, собственно, понять, что иллюстрирует собой эта быстро
растущая синяя кривая: что-то искусственное или то, о чем я пишу выше.
> > Потому и нужно произвести деление дистрибутива на (грубо говоря)
> > системный софт + библиотеки и десктопный софт + тулкиты и отказаться
> > от глобального фриза. Получился бы и не вариант убунты, где нестабильно
> > всё подряд, и не текущий вариант, где stable == static.
>
> Стабильность (в смысле неизменчивость) разным людям нужна в разных частях
> дистрибутива. Деление, удовлетворяющее всех, невозможно.
> Текущая ситуация (stable + минимум backports) кажется правильнее.
> Каждый может поставить именно ту свежатинку, которая именно ему нужна.
> А нужна она не так уж и часто (я имею в виду нужна для конкретной цели, а не
> ддля удовлетворения жажды новых версий).
К сожалению даже при этом число пакетов, которые я сам собираю/бакпорчу
быстро разрастается до того, что уследить за ними становится сложно.
--
Stanislav
Reply to: