Марк считает 6-месячные релиз-циклы великолепной идеей, но поднимает в своей статье вопросы по поводу более длительных циклов разработки (в 2-3 года), которые необходимы для предоставления продолжительной и качественной поддержки выпускаемых продуктов.
Марк Шатлворт:
Практика регулярных релизов становится широко распространенной (kernel, GNOME и KDE, X, дистрибутивы: Ubuntu, Fedora). Идея регулярных и предсказуемых релиз-циклов получила признание.
Но необходимо признавать недостатки:
- сложно сообщить пользователям о существенных изменениях;
- трудность поддержки, т.к. невозможно поддерживать каждый релиз продолжительное время.
Основные дистрибутивы, как правило, имеют «большой» релиз, а между ними более частые релизы. RHEL -> Fedora, Ubuntu LTS -> Ubuntu, Debian придерживается похожей стратегии, но не выпускает промежуточных версий.
С выходом 8.04 LTS, мы говорили, что было бы неплохо сказать заранее, когда выйдет следующий LTS дистрибутив. Я считал, что это будет 10.04 LTS (основной двухлетний цикл). Но тогда не будет возможности координироваться с основными релизами других крупных дистрибутивов - Debian, Suse или Red Hat.
В беседах со Стивом Макинтайером (нынешний лидер проекта Debian) мы выявили интересные возможности для сотрудничества. Debian стремится к 18-месячному циклу, в котором их следующий релиз выйдет где-то в октябре 2010 года. Примерно в то же время выйдет релиз Ubuntu 10.10. Мы могли бы отложить Ubuntu LTS до 10.10. Это позволит сделать обмен патчами много проще. На конференции в Барселоне в мае у нас будут хорошие возможности изучить эту возможность в деталях.
Я говорил также с людьми из Novell, но они не разделяют мое точку зрения на данный момент.
Итак, основные вопросы, которые интересуют меня:
- Какие вещи должны быть рассмотрены при планировании мета-циклов? Какие проблемы они вызывают и каким образом лучше всего их решать? Какие короткие циклы (3 месяца, 6 месяцев) лучше вписываются в более длительный мета-цикл?
Подходит ли название мета-цикл к описанию длительных циклов?
- Стоит ли «первый релиз из основного цикла» (KDE 4.0, Python 3.0) делать как короткий цикл, который не получит долгосрочной поддержки?
- Какой релиз из «длительных циклов» лучше всего подходит для долгосрочной поддержки? Это последний из релизов, до начала новых крупных изменений (Python 2.6; GNOME 2.28)? Или же релиз, следующий после выхода новой ветки разработки (KDE 4.2; GNOME 3.2)? Это важно, потому что крупные организации хотят более длительной поддержки?
- Каков должен быть основной цикл разработки? Я придерживаюсь мнения - 2 года. Но в неформальных разговорах об этом некоторые люди говорили о 18 месяцах, а другие заявляли о 30 месяцах (2,5 лет). Я думаю, они сумашедшие, что вы думаете?
- Стоит ли проектам, связанным с аппаратной частью, иметь собственный цикл разработки, отличающийся от более высокоуровневых проектов?
- Что делать с такими проектами как GCC, X, OpenOffice?
Пожалуйста, напишите, что вы думаете обо всем этом. Я уверен, что вместе мы сможем выйти на совершенно новый уровень разработки, если сможем договориться о новой модели выхода релизов.
>>> Подробности (markshuttleworth.com)
