Руководство по подаче изменений

В целом изменения служат для координации усилий по разработке и для коммуникации (как внутренней, так и внешней). Они не являются мандатами, обязывающими кого-то другого реализовать идею (какой бы хорошей эта идея ни была). Если вы задумали улучшение, постарайтесь заручиться обязательством исполнителей до подачи предложения об изменении, вместо того чтобы ожидать, что они появятся для работы после принятия изменения.

Посмотрите видео о политике изменений Fedora для краткого введения в процесс.

Как предложить новое изменение?

Чтобы предложение об изменении было рассмотрено как официальное и принято для следующего выпуска Fedora Linux, оно должно быть формально задокументировано на отдельной вики-странице.

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

  1. Создайте новую вики-страницу

    1. Войдя в систему, нажмите кнопку View Source на странице пустой формы предложения об изменении.

    2. Скопируйте содержимое

    3. Измените URL на https://fedoraproject.org/wiki/Changes/<YourTitle> (заменив «<YourTitle>» на идентификатор для вашей страницы, например «ExampleChangeProposal»)

    4. Нажмите «Создать»

    5. Вставьте содержимое

  2. Заполните необходимые сведения для выбранной категории (см. встроенные комментарии и руководство ниже).

  3. Когда вы будете удовлетворены страницей предложения об изменении, установите категорию вики-страницы в ChangeReadyForWrangler, и установите соответствующую категорию изменения (SelfContainedChange или SystemWideChange). Обе категории должны быть установлены.

  4. Нажмите кнопку Save Changes

При желании вы можете удалить HTML-комментарии в шаблоне.
Обязательно завершите своё предложение об изменении до крайнего срока подачи предложений об изменениях! Если вы не уложитесь в этот срок, вам придётся запрашивать исключение у FESCo.

Архитектор операций отвечает за фактическое объявление предложения об изменении, создание заявки в FESCo и отслеживающей ошибки в Bugzilla.

Как показать статус изменения, которым я владею?

Ход разработки отображается в Bugzilla с определёнными состояниями ошибок, как объяснено в шаблоне предложения об изменении. Используйте эту отслеживающую ошибку, чтобы показать блокирующие факторы, с помощью полей Blocks/Depends on (например, проверки пакетов), обновите описание ошибки фактическим статусом и измените статус ошибки в соответствии с текущим состоянием. Архитектор операций или члены FESCo могут попросить вас предоставить более подробный статус (особенно для общесистемных изменений).

Изменение считается завершённым на уровне кода, когда состояние ошибки переведено в ON_QA и нет открытых блокирующих ошибок.

См. раздел Отслеживание в Bugzilla политики изменений для получения дополнительной информации о статусах Bugzilla.
В большинстве случаев вам не следует отправлять изменения кода в Rawhide до тех пор, пока FESCo не проголосует за одобрение предложения.

Каковы крайние сроки процесса изменений (контрольные точки)?

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

Что, если я не завершу изменение?

Изменения, которые не могут быть завершены к выпуску, автоматически откладываются до следующего выпуска. Вам не нужно повторно предлагать изменение, если только вы не вносите в него существенные правки. Если вам нужно отложить изменение, сообщите об этом Архитектору операций, и он соответствующим образом обновит вики-страницу и отслеживающую ошибку в Bugzilla.

Что, если мне нужно изменить своё изменение?

Незначительные изменения можно вносить в любое время. Если у вас есть существенные изменения после одобрения изменения, обратитесь за одобрением к FESCo.

Руководство по разделам

Название предложения об изменении

Оно должно быть описательным, но уникальным. Например, «glibc 2.29» предпочтительнее, чем «обновление glibc».

Убедитесь, что ваша страница находится в пространстве имён Changes (например, назовите её Changes/glibc_2.29)

Краткое описание

Одно-два предложения, резюмирующих, что представляет собой это изменение и что оно будет делать. Эта информация используется для общей сводной страницы набора изменений для каждого выпуска. Обратите внимание, что мотивация изменения должна быть в разделе «Мотивация» ниже, а эта часть должна отвечать на вопрос «Что?», а не «Почему?».

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

Владелец

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

Используйте свою электронную почту Bugzilla в поле email, чтобы порадовать своего Архитектора операций.

Текущий статус

Не редактируйте этот раздел, кроме как для указания целевой версии выпуска и обновления тегов [[Category:*]].

Подробное описание

При необходимости раскройте краткое описание. Нескольких предложений достаточно, чтобы объяснить цель, но чем больше деталей вы сможете предоставить, тем лучше. Если есть несколько разумных подходов, вам следует указать, почему вы отказались от использования других.

Обратная связь

Резюмируйте обратную связь от сообщества и объясните, почему вы решили не принимать предложенные альтернативы. Этот раздел необязателен для всех предложений об изменениях, но настоятельно рекомендуется. Включение обратной связи сюда по мере её поступления даёт FESCo более чёткое представление о вашем предложении и оставляет хорошую запись для будущего. Если вы не получаете обратной связи, это также полезно отметить в этом разделе. Этот раздел частично вдохновлён разделом «Отклонённые идеи», описанным в PEP-0001.

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

Вам следует заполнять этот раздел по мере получения обратной связи. Поскольку он необязателен, Архитектор операций не должен ждать, пока вы завершите этот раздел, прежде чем отправить его в FESCo. Если обсуждение станет жарким, рассмотрите возможность попросить нейтральную сторону резюмировать обсуждения для вас. Это помогает избежать предвзятости и эмоциональной реакции.

Преимущества для Fedora

Какова польза для дистрибутива? Улучшится ли программное обеспечение, которое мы создаём? Как улучшится процесс создания выпусков Fedora Linux?

Обязательно включите следующие области, если они актуальны:

  • Если это крупное обновление возможностей, что изменилось? Например: это изменение вводит Python 5, который работает без глобальной блокировки интерпретатора и полностью многопоточен.

  • Если это новая функциональность, какие возможности она приносит? Например: это изменение позволяет выполнять обновления пакетов автоматически и откатывать их по желанию.

  • Улучшает ли это какой-то конкретный пакет или набор пакетов? Например: это изменение модифицирует пакет для использования другого языкового стека, что уменьшает размер установки за счёт удаления зависимостей.

  • Улучшает ли это конкретные Spin или Edition? Например: это изменение модифицирует установку Fedora Workstation по умолчанию, чтобы она больше соответствовала базовой установке Fedora Server.

  • Делает ли это дистрибутив более эффективным? Например: это изменение заменяет тысячи отдельных %post-скриптлетов в пакетах одним скриптом, который выполняется в конце.

  • Является ли это улучшением процессов сопровождающих? Например: гейтинг пакетов Fedora по автоматическим тестам QA сделает rawhide более стабильным и позволит реализовывать изменения более гладко.

  • Является ли это улучшением, нацеленным на конкретных участников? Например: обеспечение того, что минимальный набор инструментов, необходимых для участия в Fedora, установлен по умолчанию, облегчает адаптацию новых участников.

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

Область

  • Владельцы предложения: какую работу должны выполнить владельцы функции, чтобы завершить её вовремя к выпуску? Это крупное изменение, затрагивающее многие части дистрибутива, или очень изолированное изменение? Каковы эти изменения?

  • Другие разработчики: ТРЕБУЕТСЯ ДЛЯ ОБЩЕСИСТЕМНЫХ ИЗМЕНЕНИЙ Какую работу должны выполнить другие разработчики, чтобы завершить функцию вовремя к выпуску? Это крупное изменение, затрагивающее многие части дистрибутива, или очень изолированное изменение? Каковы эти изменения?

  • Релиз-инжиниринг: ТРЕБУЕТСЯ ДЛЯ ОБЩЕСИСТЕМНЫХ ИЗМЕНЕНИЙ Требует ли эта функция координации с релиз-инжинирингом (например, изменения в генерации образов установщика или доставке пакетов обновлений)? Требуется ли массовая пересборка? Включите ссылку на заявку releng. Заявка должна быть подана до отправки функции, чтобы гарантировать, что кто-то готов выполнить работу по разработке процесса и тестированию, и что все изменения попадут в конвейер; пункт в изменении не является достаточной коммуникацией.

  • Политики и руководства: нужно ли обновлять руководства по упаковке или другие документы для этой функции? Если да, должно ли это произойти до или после завершения реализации? Если существует заявка FPC, добавьте ссылку здесь. Где возможно, подайте pull request к соответствующим документам политики до отправки предложения об изменении. Так сообщество и FESCo смогут оценить конкретные требуемые изменения.

  • Одобрение товарного знака: если ваше изменение может потребовать одобрения товарного знака (например, если это новый Spin), подайте заявку в Совет Fedora с запросом на одобрение товарного знака.

  • Соответствие целям: соответствует ли ваше предложение текущим целям Fedora? Это будет применимо не ко многим изменениям, но важно учитывать при предложении изменения. Несоответствие не является автоматическим отклонением, это всего лишь ещё один аспект для рассмотрения.

Влияние на обновление/совместимость

ТРЕБУЕТСЯ ДЛЯ ОБЩЕСИСТЕМНЫХ ИЗМЕНЕНИЙ Что произойдёт с системами, на которых были установлены предыдущие версии Fedora Linux и которые обновляются до версии, содержащей это изменение? Потребует ли что-либо ручной настройки или миграции данных? Будет ли какая-либо существующая функциональность больше не поддерживаться?

Как тестировать

ТРЕБУЕТСЯ ДЛЯ ОБЩЕСИСТЕМНЫХ ИЗМЕНЕНИЙ Это не обязательно должен быть полноценный документ. Опишите аспекты тестов, которые эта реализация изменения должна пройти по завершении. Если её нужно тестировать с различными конфигурациями оборудования или программного обеспечения, укажите их. Чем конкретнее вы будете, тем лучше сможет быть тестирование сообществом.

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

Хорошее руководство «как тестировать» должно отвечать на эти четыре вопроса:

  1. Какое специальное оборудование / данные / и т. д. требуются (если вообще требуются)?

  2. Как мне подготовить свою систему для тестирования этого изменения? Какие пакеты нужно установить, конфигурационные файлы отредактировать и т. д.?

  3. Какие конкретные действия мне выполнить, чтобы проверить, что изменение работает так, как задумано?

  4. Каковы ожидаемые результаты этих действий?

Пользовательский опыт

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

Этот раздел частично пересекается с разделом «Преимущества для Fedora» выше. Этот раздел должен быть в первую очередь о пользовательском опыте, написан так, чтобы не предполагать глубоких технических знаний. Более подробное техническое описание следует оставить для раздела «Преимущества для Fedora».

Опишите, что пользователи увидят или заметят, например:

  • Пакеты сжимаются более эффективно, что делает загрузки и обновления быстрее на 10%.

  • Билеты Kerberos могут обновляться автоматически. Теперь пользователям придётся аутентифицироваться реже и они станут более продуктивными. Улучшения управления учётными данными означают, что пользователь может начать свой рабочий день с единого входа и ему не придётся прерываться на повторную аутентификацию в течение всего дня.

  • LibreOffice — одно из наиболее часто устанавливаемых приложений в Fedora Linux, и теперь оно доступно по умолчанию, чтобы помочь пользователям «сразу приступить к работе».

  • Научно доказано, что зелёный — самый расслабляющий цвет. Переход к цвету фона по умолчанию зелёному с зелёным текстом приведёт к тому, что пользователи Fedora Linux станут самыми расслабленными пользователями среди всех операционных систем.

Зависимости

ТРЕБУЕТСЯ ДЛЯ ОБЩЕСИСТЕМНЫХ ИЗМЕНЕНИЙ Какие другие пакеты (RPM) зависят от этого пакета? Есть ли изменения вне контроля разработчиков, от которых зависит завершение этого изменения? Иными словами, завершение другого изменения, принадлежащего кому-то другому, которое может помешать вам завершить вовремя или потребовать координации? Другие проекты апстрима, такие как ядро (если это не изменение ядра)?

План на случай непредвиденных обстоятельств

ТРЕБУЕТСЯ ДЛЯ ОБЩЕСИСТЕМНЫХ ИЗМЕНЕНИЙ Если вы не сможете завершить свою функцию к окончательной заморозке разработки, каков запасной план? Это может быть так просто, как «откатить поставленную конфигурацию». А может и нет (например, пересборка ряда зависимых пакетов). Если ваша функция не будет завершена вовремя, мы хотим заверить других, что другие части Fedora не окажутся под угрозой.

План на случай непредвиденных обстоятельств должен включать:

  • Механизм действий в непредвиденных обстоятельствах: (Что делать? Кто будет это делать?)

  • Крайний срок действий в непредвиденных обстоятельствах: когда в последний раз механизм действий в непредвиденных обстоятельствах может быть задействован?

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

Документация

ТРЕБУЕТСЯ ДЛЯ ОБЩЕСИСТЕМНЫХ ИЗМЕНЕНИЙ Есть ли документация апстрима об этом изменении или заметки, написанные вами самим? Дайте ссылку на этот материал здесь, чтобы другие заинтересованные разработчики могли присоединиться.

Примечания к выпуску

Примечания к выпуску Fedora Linux информируют конечных пользователей о том, что нового в выпуске. Примеры прошлых примечаний к выпуску находятся на Fedora Docs. Примечания к выпуску также помогают пользователям узнать, как справляться с изменениями платформы, такими как ABI/API, форматы конфигурационных или файлов данных, или проблемами обновления. Если это изменение включает какие-либо такие изменения, укажите их здесь. Ссылка на документацию апстрима часто удовлетворит эту потребность. Эта информация составляет основу примечаний к выпуску, редактируемых командой документации и поставляемых с выпуском.

Want to help? Learn how to contribute to Fedora Docs ›