Поток работы Grafana

Документ основан на GOVERNANCE.md. Мы предполагаем добрые намерения и стремимся сохранить все процессы как можно более легкими, но при этом достаточно конкретными. В случае разногласий по любому вопросу, описываемому в этом документе, применяется GOVERNANCE.md.

Ключевые слова "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" и "OPTIONAL" в этом документе должны интерпретироваться в соответствии с RFC2119.

Терминология Git и GitHub используется на протяжении всего документа.

Члены команды и их доступ к репозиториям поддерживается через команды GitHub. Модераторы команд добавляют и удаляют членов команд в соответствии с описанным в GOVERNANCE.md.

Изменения кода

Предложение изменений

Примерами предложенных изменений являются общая архитектура, дизайн компонентов и конкретные элементы кода или графики. Предложенные изменения SHOULD охватывать общую картину и намерения, но отдельные части SHOULD быть разделены на наименьшие возможные изменения. Изменения SHOULD основываться на и направлены на основную ветку. В зависимости от размера предложенного изменения каждое изменение SHOULD обсуждаться в порядке возрастания размера и сложности изменений:- Прямое обсуждение в PR (Pull Request) - это МОЖЕТ быть сделано, но ДОЛЖНО не быть обычным случаем.

• Задача (Issue)
• Список рассылки разработчиков
• Документ дизайна, разделяемый через Google Docs, доступный для всех членов команды.

Значительные изменения ДОЛЖНЫ быть обсуждены и одобрены соответствующими модераторами подсистем.

Объединение PR (Pull Requests)

В зависимости от размера и сложности PR должны применяться различные требования. Любой член команды, substantially участвующий в PR, ДОЛЖЕН быть исключен из числа требований для проверки.

Коммиты ДОЛЖНЫ быть объединены в основную ветку через PR. Они НЕ ДОЛЖНЫ быть объединены в основную ветку напрямую.

• Каждое объединение ДОЛЖНО быть одобрено по крайней мере одним членом команды.

• Нетривиальные изменения ДОЛЖНЫ быть одобрены по крайней мере

  • двумя членами команды, или
  • одним модератором подсистемы.

• Значительные изменения ДОЛЖНЫ быть одобрены по крайней мере

  • двумя членами команды, И
  • соответствующим модератором подсистемы.Запросы на внесение изменений (PRs) ДОЛЖНЫ быть проверены и одобрены через систему проверки GitHub.

• Проверяющие МОГУТ оставлять комментарии при одобрении

• Проверяющие ДОЛЖНЫ оставлять комментарии при отклонении PR или при запросе изменений.Как только PR будет одобрен в соответствии с вышеуказанными принципами, любой участник команды МОЖЕТ объединить PR.

Перенос PR

Критические исправления ошибок, необходимые для предыдущего минорного выпуска, ДОЛЖНЫ быть перенесены на соответствующие ветки выпуска после согласования с командой доставки. Дополнительные сведения см. в руководстве по вкладу.

Поток выпуска

Структура веток

Grafana использует разработку на основе основной ветки.

В частности, мы обнаружили, что следующие принципы соответствуют тому, как мы работаем:

• Основная и ветки выпуска ДОЛЖНЫ всегда собираться без ошибок.
• Ветки ДОЛЖНЫ часто объединяться. Большие изменения ДОЛЖНЫ активироваться с помощью флагов функций до тех пор, пока они не будут готовы. Долгосрочные ветки разработки ДОЛЖНЫ избегаться.
• Изменения МОГУТ быть включены по умолчанию, как только они будут в полной мере.
• Изменения, которые охватывают несколько PR, ДОЛЖНЫ быть описаны в общей задаче или Google Docs.

Выпуски

Выпуски ДОЛЖНЫ следовать семантическому версионированию в названии и ДОЛЖНЫ следовать семантическому версионированию как можно ближе для программного обеспечения, не являющегося библиотекой.Ветки выпуска ДОЛЖНЫ быть разделены от последующих веток.

• Ветки основных выпусков ДОЛЖНЫ быть основаны на основной ветке.
• Ветки минорных выпусков ДОЛЖНЫ быть основаны на основной ветке.
• Ветки патч-выпусков ДОЛЖНЫ быть разделены от актуальной ветки минорного выпуска.

Выпуски безопасности следуют тому же процессу, но ДОЛЖНЫ быть подготовлены в секрете. Выпуски безопасности ДОЛЖНЫ не включать изменения, не связанные с исправлением безопасности. Обычные процессы выпуска ДОЛЖНЫ учитывать процесс выпуска безопасности. ДОЛЖНЫ следовать SECURITY.md.

Выпуски следуют следующему темпу:

• Основные: Раз в год
• Минорные: Каждые 4-6 недель
• Патчевые: По мере необходимости

Выпуски ДОЛЖНЫ не задерживаться из-за ожидающих изменений.

Выпуски ДОЛЖНЫ быть согласованы с соответствующими подсистемными поддерживателями.