На конференции Akademy 2008, собравшей более 350 представителей со всех стран мира, члены выпускающей команды KDE Sebastian Kügler и Dirk Müller изложили свое видение стратегии дальнейшего развития среды рабочего стола. Были высказаны трудности, с которыми сталкивается KDE и возможные варианты их решения, вызвавшие жаркие дебаты.
Модель разработки среды KDE за 10 лет существования претерпела лишь незначительные изменения и на настоящий момент не удовлетворяет темпам ее развития:
За 8 лет, которые потребовались для перехода с KDE 0.0 до 3.5, в системе управления версий было зафиксировано 420 000 изменений.
За последние 2 года обновление с KDE 3.5 до 4.0 потребовало 300 000 изменений.
Такой значительный рост создает трудности как для разработчиков, так и для выпускающей команды. Принятие решений по присланным патчам, отслеживание их статуса с ростом проекта становятся все более сложными задачами. Централизованная система контроля версий Subversion плохо поддерживает групповую работу. В итоге шестимесячный цикл работы превращается в 3 месяца разработки с последующим трехмесячным тестированием, вместо теоретических 4 и 2 месяцев.
За прошедшее время возникло множество вопросов, требующих немедленного решения: не всем подходит 6-ти месячный цикл выпуска релизов, система Subversion далека от идеала, организации, вовлеченные в работу над KDE, имеют свои планы выпуска и обязательства перед клиентами, поэтому то, что выглядит достаточно стабильным для одних является неприемлемым для других. С появлением новых инструментов для разработки и взаимодействия, включая распределенную систему контроля версий Git, появились новые перспективы для развития. KDE находится в процессе расширения списка поддерживаемых устройств, операционных систем (OpenSolaris, Windows, Mac OS) и мобильных платформ (Maemo). Так же важным моментом является повышение эффективности сотрудничества с другими свободными проектами и сторонними разработчиками. По мнению Sebastian Kügler и Dirk Müller развитие проекта должно быть динамичным и рассредоточенным, сводя к минимуму время «заморозки» основной ветки, связанное со стабилизацией кода.
|