Xfce

Subdomains

 

Модель выпуска

В прошлом перед выпуском каждой новой версии снова и снова возникали одни и те же вопросы и обсуждения, такие как:

  • Какие компоненты являются основными в Xfce?
  • Как часто мы хотим делать выпуски и каким образом (по времени или по особенностям)?
  • Кто отвечает за процесс выпуска?
  • Какие версии зависимостей нам нужны?
  • Когда производить заморозку функционала, заморозку строк, заморозку кода и тому подобное?
  • Сколько должно быть предварительных выпусков и как их называть?
  • Что мы используем в качестве замены для SVN-ревизий в Git?

Данный документ призван ответить на эти вопросы и определить политику, которой мы можем следовать при планировании выпусков.

Основная оболочка Xfce

Основные компоненты

  • exo
  • gtk-xfce-engine
  • libxfce4ui
  • libxfce4util
  • thunar
  • thunar-volman
  • xfce4-appfinder
  • xfce4-panel
  • xfce4-session
  • xfce4-settings
  • xfconf
  • xfdesktop
  • xfwm4
  • garcon
  • tumbler
  • xfce4-power-manager

Все основные компоненты рабочего стола Xfce должны придерживаться политики выпуска, определённой в этом документе.

Необходимые зависимости

  • GTK+
  • GLib

Цикл выпуска

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

Ниже представлена графическая хронология цикла выпуска и сопровождения на примере выпуска Xfce 4.8 с тремя компонентами: Thunar, exo и xfwm4.

example-release-cycle

Пример цикла выпуска

Фаза планирования (2 (+ 2) недели)

Этот этап знаменует начало цикла выпуска и используется для определения какие зависимости использовать, а также назначить команду выпуска для цикла (первые 2 недели). В конечном итоге, это приводит к замораживанию зависимости (через 4 недели).

Назначение команды выпуска

В начале фазы планирования (формально или неформально) происходят выборы команды выпусков. Команда выпуска инспектирует разработку и сопровождение выпуска в течении цикла выпуска. Главной целью является достижение и перепроверка выпуска ядра рабочего стола Xfce в фазе выпуска, ближе к концу цикла. Это более детально разъяснено в разделе Команда выпуска в этом документе.

Команда выпуска

Команда выпуска состоит во всяком случае из двух человек: один менеджер выпуска который может помогать другим фактически осуществлять выпуск (разметка, создание тарболов, написание заметок к выпуску и объявлений), и другой человек для обеспечения качества (проверка все ли компоненты скомпилированы, метки на местах, заметки к выпуску обновлены и так далее). Более детально это определено ниже.

Задачи и обязанности команды выпуска:

Управляющий выпуском

  1. Организация цикла выпуска
  2. Объявление окончательных сроков разработчикам и переводчикам (неоднократно и заранее)
  3. Наблюдение за сопровождением и разработкой выпусков
  4. Пометка Xfce-X.Ypre1, Xfce-X.Y.pre2, Xfce-X.Y.pre3 и Xfce-X.Y
  5. Создать tar-архивы из меток (возможно, автоматизированно)
  6. Написание замечаний о выпуске
  7. Написание объявлений о выпуске
  8. Создание меток Bugzilla
  9. Утверждать исправления блокировки ошибок на стадии заморозки кода

Помощник(и) выпуска

  1. Обновление сайта(ов)
  2. Помощь управляющему выпуском с его задачами

Обеспечение качества

  1. Следить за версиями libtool при сопровождении и разработке выпусков
  2. Напоминание сопровождающим об обновлениях NEWS-фалов
  3. Перепроверка созданных tar-архивов
  4. Перепроверка анонсов о выпуске

Индивидуальные сопровождающие

  1. Создать компоненто-зависимые метоки для сопровождаемых и разрабатываемых выпусков
  2. Создать tar-архивы для сопровождаемых и разрабатываемых выпусков
  3. Написание файлов ChangeLogs (перечень изменений) и обновление файлов NEWS (новостей)
  4. Написание анонсов о выпуске компонентов
  5. Создание меток Bugzilla для соответствующих выпусков
  6. Проверка актуальности документации по API

Заморозка зависимостей

В течение первых двух недель фазы планирования каждому сопровождающему необходимо

  1. Составить список функций, которые он хочет реализовать в цикле выпуска
  2. Выяснить какие зависимости это подразумевает

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

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

По окончании этих 4 недель, для всех компонентов вводят заморозку зависимостей от которых они зависят, что означает невозможность изменения зависимостей (и их версий). Дополнительные зависимости тем не менее по прежнему разрешено добавлять.

Оповещение сообщества

В самом конце фазы планирования в списки рассылки xfce4-dev@xfce.org и xfce@xfce.org отправляется сообщение с перечислением запланированных возможностей и зависимостей для всех основных компонентов Xfce.

Фаза разработки (5 месяцев)

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

Опытные выпуски

Опытные выпуски обычно дают предварительное представление о функциях следующих стабильных выпусков. Они должны следовать формату версий X.Y.Z, где Y нечетное число (например, xfwm4-4.7.3 или thunar-1.3.10).

Сопровождающим рекомендуется делать опытные выпуски включающие новый функционал, который они хотят сделать доступным для других. Частые опытные выпуски могут быть заменой управлению версиями SVN-ревизий, что было в прошлом. Если компонент A зависит от нового функционала компонента B, то компонент A может быть выпущен, только если опытный выпуск компонента B включает в себя этот новый функционал. Чтобы это работало, версии libtool должны быть обновлены должным образом с каждым опытным выпуском.

В отношении мастер-ветви каждого компонента должна быть проявлена осторожность. Мастер-ветвь должна всегда оставаться в состоянии готовом к выпуску. Новые функции должны разрабатываться в ветвях до тех пор пока они не готовы (а именно: компонент будет оставаться функциональными даже после включения функции(ий) в мастер-ветвь), для уменьшения риска задержки финального выпуска всего ядра рабочего стола Xfce.

Новые функции, ломающие API или другие основные компоненты, должны быть обсуждены. Сопровождающим предложено подготовить другие компоненты для этих функций в отдельной ветви, до включения их в новый опытный выпуск. Таким образом другие компоненты сохраняются в состоянии готовом к выпуску.

Вот как выглядит основная часть разработки:

feature-branching

Ход разработки

Фаза выпуска (10+ недель)

В течение фазы выпуска выходят три предварительных выпуска и один конечный выпуск:

  1. Xfce X.Ypre1 (после 0 недель, заморозка функций),
  2. Xfce X.Ypre2 (после 4 недель, заморозка строк) и
  3. Xfce X.Ypre3 (после 8 недель заморозка кода)
  4. Xfce X.Y (после 10+ недель)

где Y должно быть четным числом. Каждый из этих выпусков включает позднейшие опытные выпуски всех компонентов (или стабильные, если там не было опытных выпусков после последнего стабильного выпуска) ядра оболочки Xfce. Номера версии этих компонентов могут (даже должны) отличаться от вышеуказанной схемы наименования. Например для Xfce 4.8.0pre2, xfwm4 мог иметь версию 4.7.17 и Thunar мог иметь 1.1.9.

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

Окончание этой фазы отмечает новый стабильный выпуск ядра оболочки Xfce и вместе с тем начало цикла нового выпуска.

Заморозка перед выпусками

Существуют различные типы заморозок перед выпусками.

Заморозка функций

С Xfce X.Ypre1 все основные компоненты входят в фазу заморозки функций. Это означает, что в основную ветку принимаются только переводы и исправления ошибок.

Заморозка строк/пользовательского интерфейса

С Xfce X.Ypre2 все основные компоненты входят в фазу заморозки строк / пользовательского интерфейса. Это означает, что нельзя изменять строки, которые влияют на переводы. То же касается пользовательского интерфейса, который нельзя изменять после наступления этой стадии.

Заморозка кода

Каждому предварительному выпуску предшествует двухдневная заморозка кода. Во время заморозки в сетевом хранилище не могут быть сделаны изменения не подписанные управляющим выпуска.

С Xfce X.Ypre3 все основные компоненты входят в фазу заморозки кода, означающую возможность изменения кода, только если оно будет одобрено управляющим выпуска. Это обычно применимо только в случае исправления блокирующих или критичных для выпуска ошибок. Переводы в фазе заморозки всё ещё допустимы.

Фаза заморозки кода (2+ недели)

С выходом Xfce X.Ypre3 заморожен код всех основных компонентов. Данная фаза показана на следующем изображении и подробнее объяснена в этом разделе.

Заморозка кода и исключения из заморозки поддерживаются обработчиками отправки. Также есть обработчики обновления, которые не позволяют вносить изменения в мастер-ветвь, если эти изменения не были подписаны управляющим выпуска.

code-freeze-branching

Пометки и ветвление выпусков

Исправления / изменения

Если основной компонент требует исправления или изменения во время заморозки кода, сопровождающий должен создать новую ветвь с названием ELS (//НАЗВАНИЕ ОТКРЫТО ДЛЯ ОБСУЖДЕНИЯ//), которую он или она затем передают для исправления. Передача в секцию Исключения при заморозке кода происходит если это критичные для выпуска изменения или исправления для блокировки ошибок.

Ветвь ELS существует короткий период времени. Она объединяется с мастер-ветвью и со стабильной ветвью компонента (например xfwm4-4.8 или thunar-1.2) после финального выпуска. В этой ветви допустимы только исправления ошибок.

Исключения при заморозке кода

Блокирующие ошибки

Некоторые ошибки могут вызвать задержку финального выпуска, если они признаны блокирующими. Это так, если они:

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

Ошибка может не задерживать выпуск, если она соответствует следующим критериям:

  • оборудование или архитектура, на которых происходит ошибка, являются экзотическими и/или у разработчиков нет способа воспроизвести данную ошибку

Исправление этих ошибок допустимо применять во время заморозки кода если, и только если они поддержаны менеджером выпуска.

Важные для выпуска изменения

Некоторые изменения могут повлечь большие проблемы с уважением к качеству выпуска. Они допустимы для внесения если, и только если они поддержаны менеджером выпуска.

Выпуск

Для финального выпуска (Xfce X.Y), все основные компоненты размечаются (дважды, один раз своей собственной версией и один раз как xfce-X.Y.0) и ответвляются для цикла поддержки (например, как thunar-1.2 или xfwm4-4.8). После этого, выполняется объединение ветви ELS с основной (где происходит разработка следующего выпуска) и с ветвями, например, на thunar-1.2 или xfwm4-4.8.

Сопровождение

После выхода финальной версии, исправления и обновления переводов будут отправлены в стабильную ветвь конкретного компонента (например, thunar-1.2 или xfwm4-4.8). От выпусков сопровождения отдельных компонентов не требуется, чтобы они были синхронизированы.

Выпуски сопровождения

В выпусках сопровождения не допускается изменения API/ABI по сравнению с соответствующим финальными выпусками Xfce-окружения. Также они должны соответствовать формату версий X.Y.Z, где Y является чётным числом (например, xfwm4-4.8.4 или thunar-1.2.4). Никакие новые функции или сообщения не могут быть добавлены в этих выпусках.

Авторы

  • Jannis Pohlmann <gro.ecfx@sinnaj>
  • Stephan Arts <gro.ecfx@nahpets>