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