Центр управления Mandriva Linux

Mandriva Linux с самого начала позиционировала себя как дружелюбный к пользователю дистрибутив, предоставляющий приятный внешний вид, большой выбор программ, а также удобные средства работы с системой в виде «Центра управления Mandriva». Развитие инструментов, наподобие NetworkManager, а также стагнация в разработке аналогичных инструментов в «Центре управления Mandriva», приводит к отставанию дистрибутива в целом. Например, в «Сетевом центре» до сих пор отсутствует поддержка MS VPN, а также нормальная работа с 3G-модемами. С другой стороны, в NetworkManager эти возможности уже давным-давно реализованы.
Одной из самых главных проблем «Центра управления» можно назвать устаревшую кодовую базу, написанную на Perl с привязкой к GTK+. Сам код недостаточно хорошо документирован, а его поддержка и сопровождение становятся всё проблематичнее. На это косвенно указывает тот факт, что с функциональной точки зрения «Центр управления» не развивается уже несколько лет (внешний вид в расчёт не беру). Собственно, всё то новое, что появлялось в «Центре управления» за последнюю пару лет было написано Евгением Додоновым уже на Python.

Кстати, затрагивая вопрос выбора подходящего языка программирования, вероятно именно Python может выступить в качестве основного языка для создания инструментов Mandriva.
Python обладает следующими очевидными преимуществами над Perl:

• Python имеет целый спектр привязок к основным системам графического интерфейса (Qt3/4, GTK+, WxWidgets). К примеру, Perl до сих пор не имеет нормальной привязки к Qt4.
• Код, написанный на Python, легче читается и сопровождается.
• Python прост в изучении.

Хотя бы три первых пункта уже позволяют сделать однозначный выбор в пользу этого языка программирования.

Спецификации

Перед непосредственным началом выполнения работ над новым релизом традиционно выполняется этап сбора/анализа требований и предложений, которые ложатся в основу спецификаций для будущей системы.

До недавнего времени, участие сообщества на этом этапе жизненного цикла дистрибутива было практически нулевым. Mandriva Ideas почти не принималась во внимание разработчиками, а предложения, опубликованные в Mandriva Wiki обрабатывались весьма вяло.
Также имеется необходимость явно отслеживать ход выполнения спецификаций (хотя бы на основе самого просто списка задач с выставлением соответствующих процентов, как это сделано в том же GNOME или KDE). До этого форма отчётности по выполнению спецификаций носила свободный характер, результатом этого являлась публикация соответствующего документа на Wiki в произвольные сроки.

Отсутствие средств мониторинга выполнения спецификаций — явный «минус» текущей системы. Показателен тот факт, что некоторые спецификации кочевали в планах от релиза к релизу, но так и не были реализованы. Так, например, спецификация о портировании графического движка IaOra на Cairo «висела» 2 года, а работы по её выполнению даже не начинались.

В перспективе, реализация некритичных и мало приоритетных задач может решаться даже активными членами сообщества.

Сборка пакетов

Довольно неплохо себя зарекомендовала практика менторства. На данном направлении можно предложить ещё одну инициативу — совместная сборка пакета с опытным мейнтейнером. Это позволит снизить планку для участников, которые желают научиться собирать пакеты, но не имеют достаточного опыта.

Также ощущается нехватка удобных инструментов для взаимодействия со сборочной системой, наподобие openSUSE Build Service.

Графический дизайн и оформление

Работа над дизайном Mandriva Linux всегда оставалась уделом третьих лиц, приглашённых со стороны. Сообществу предлагалось поучаствовать лишь в выборе обоев рабочего стола. В сообществе найдётся не мало людей, которые имеют пользоваться GIMP и Inkscape. Даже мне, человеку далёкому от графики, после просмотра пары скринкастов по Inkscape удалось за полчаса создать набросок countdown-таймера для будущего релиза. :)



Большинству пользователей хотелось бы работать с красивой и удобной Linux-системой. Тема оформления IaOra для своего времени была достаточно неплоха и позволила консолидировать внешний вид приложений для различных сред рабочего стола. Однако глядя на современные темы оформления в Ubuntu, Kubuntu, становится ясно, что IaOra устарела и ей на смену нужно искать новую концепцию графического дизайна. На этом фронте работ Mandriva явно не хватает собственной команды дизайнеров.

Форма взаимодействия с сообществом

До недавнего времени Mandriva практически не предпринимала попыток улучшения взаимодействия со своим сообществом. Затем, если память не изменяет, в 2009 году такая попытка была сделана: было заявлено о создании Mandriva User Group (MUG). Вкратце, MUG — это структура, созданная из представителей различных стран (как правило, одна страна — один представитель). На мой взгляд, идея MUG провалилась.

Фундаментальную причину, почему MUG не смогла эффективно себя проявить, я вижу в отсутствии чётких сформулированных целей и задач, поставленных перед этой структурой. Вклад в провал MUG сделали и сами его инициаторы: порой встречи отменялись банально из-за того, что на них виртуально не приходил никто из сотрудников Mandriva, курировавших данное направление.
Печальный опыт MUG — это лишний повод задуматься над формой сотрудничества с сообществом.

Активные и открытые команды

Когда речь заходит об участии сообщества в таком большом проекте, как Mandriva Linux, вполне логично было бы выделить составляющие разработки проекта в отдельные направления. Обычно, каждое направление требует формирования собственной активной и открытой команды участников (желательно, с участием одного или нескольких сотрудников от компании). Формально, подобная структуризация имела место в Mandriva и ранее, но часть направлений была просто «завалена» (например, web team). Этот вопрос требует отдельного обсуждения.

Мозговой штурм

Немаловажным элементом инфраструктуры для работы с сообществом является инструмент для проведения мозгового штурма. В данный момент в качестве такого приложения выступает Mandriva Ideas. К сожалению, функциональность Mandriva Ideas невелика. Но главным фактором неудачи Mandriva Ideas стало отсутствие заинтересованности со стороны разработчиков (знаю по личному опыту).

Полностью отказываться от идеи мозгового штурма нерационально. Как показывает опыт разработки ПО, мозговой штурм является достаточно эффективным методом решения задач. Что стоило бы изменить, так это форму: перевести Mandriva Ideas на открытое веб-приложение IdeaTorrent, а также активнее привлекать разработчиков и сообщество для участия в Ideas.

Механизмы разрешения конфликтов

Т. к. над Mandriva работает множество людей, вполне нормальными являются ситуации, когда между отдельными участниками и даже группами участников возникают разногласия. В данный момент явно не хватает механизмов разрешения подобных конфликтов. Применительно к вопросам сборки пакетов, вероятно, можно создать соответствующий комитет, в компетенции которого будут входить такие аспекты как: включение/исключение пакетов, применение патчей и т. д.