Что не доделано в PC-BSD 10.0-RELEASE -2: Эпичная битва за качество

Доброго времени суток.
То что PC-BSD 10.0-RELEASE вышел немного комом в общем- то не секрет. Такое бывает. Этому были свои причины. После последнего общения с Крисом мы, вроде как, эти причины окончательно выяснили и взялись исправлять и причины и следствия.

Битва с багами

Наконец то началась эпичная битва с багами! Чинится все. От старых известных проблем до косметики! Не упустите свой шанс. Если Вы знаете о проблеме (даже мелкой) потратьте три минуты на багтрекер - http://trac.pcbsd.org/ Лучшего времени для этого пока что не было.

Система формирования релизов

Внимание! Все изложенное ниже носит исключительно предварительный характер!
По результатам общения с Крисом мы, вроде как, выработали систему формирования релизов. Она пока что обсуждается, но в общих чертах, думаю, уже сформировалась. Основная проблема- отсутствие времени на стабилизацию перед релизом. Да чего там, стабилизации, как таковой, вообще не было. Надеюсь, мы придумали компромиссный вариант который устроит большинство и в то же время позволит держать темп развития.
Итак:

Формирование нового релиза

1. При формировании нового релиза будут всегда явно присутствовать стадии беты и релиз кандидата. (Это было и раньше. Дальше- интереснее)
2. На стадии беты будут стабилизироваться и отбираться возможности, которые будут включены в релиз (feature freeze). К моменту конца бета фазы все возможности должны быть зафиксированы
3. В релиз кандидаты будут включаться только исправления. Никаких новых функций, как это было в 10.0

Вообщем- то все написанное выше и так должно бы соблюдаться. Но теперь это будет задекларировано явно. И, вроде как, будет соблюдаться. Плюс образы беты и релиз кандидатов должны быть лучше анонсированы, чтобы об их существовании как минимум знали.

Обновление production ветки

Тут я остановлюсь немного подробнее. Как многие уже знают, одной из новых фич 10.0 стало появление двух наборов пакетов - Production и Edge. Первый позиционируется как стабильный набор, второй- как эксперементальный (немного похоже на Debian testing). Это позволит с одной стороны иметь стабильную ветку "поставил и забыл" для организаций, родственников и просто обычных людей. С другой- сохранить что- то похожее на Rolling release для тех кто хочет всего и сразу и готов мирится с эпизодическими багами.

Но при таком подходе есть небольшой нюанс. Связан он, в в том числе с апстримом. Перед релизом FreeBSD порты замораживаются. Это стабильно приводит, в том числе, к тому что только где- то через месяц после релиза в порты попадает новая версия KDE. В 10.0-RELEASE присутствует KDE 4.10. В Area51 на данный момент уже KDE 4.12. Более того, сразу после релиза был добавлен Cinnamon 2.0 (обновление должно уже быть  доступно в Edge). Короче говоря, нужно было придумать что- то чтобы с одной стороны пользователи production ветки использовали как можно более стабильную систему, с другой же не считали себя обделенными. Вроде как придумали:

1. Один раз в среднем в три месяца уже стабильные новшества скопом переносятся из edge в production
2. Перед этим переносом ветка Edge стабилизируется. Длится это две недели- месяц. Во время стабилизации принимается решение о том что именно уже стабильно и будет переносится. Для новшеств,  запланированных к переносу в production на протяжении периода стабилизации запрещены кардинальные изменения (только починка багов)
3. Во время стабилизации должно быть выпущено хотя бы одно- два обновления edge для того чтобы пользователи могли протестировать изменения
4. Единственный путь для того чтобы какое- то новшество попало в production- это перенос из edge как описано выше (т.е. раз в три месяца). Короче говоря production остается неизменной три месяца. ВСЕ новые фичи только в edge. В production ветку будут переносится только исправления.
5. Каждый такой перенос будет сказываться на версии production ветки. Результат каждого такого переноса будет именоваться обновлением (Update). Обновления будут нумероваться. Соответственно, версия production ветки будет вроде этой - PC-BSD 10.0 RELEASE Update 1. Если хотите, можете провести аналогию с сервис паками Windows.
6. Установочные образы будут заново формироваться для каждого обновления.

Выглядеть это должно как- то так:

Учитывая что обычно между релизами FreeBSD проходит приблизительно год и месяц, то мы будем иметь три обновления Update 1 - Update 3 для каждого релиза. В конце цикла все наработки отправляются в новый релиз.

 И еще...

Сейчас в списках рассылки происходит довольно активное шевеление. Думаю, нас ждут перемены к лучшему (я надеюсь). Некоторые новые идеи и веяния я опишу уже в следующем посте.