Кратко

  • Политики Mozilla различают одобрение владельца модуля или peer, персональный уровень доступа к репозиторию, попадание изменения в ветку и работу Release Drivers с этапами выпуска и деревьями кода.
  • В записи «от проверки до выпуска» следует отдельно сохранить модуль, изменение, роль проверяющего, основание доступа при необходимости, вошедшую ревизию, ветку, решение о выпуске и публичный артефакт.

Четыре разных действия за словом «одобрено»

Фраза «Mozilla это одобрила» может быть верной, но не давать достаточно информации для эксплуатации, поставки или поддержки. Речь идёт о review патча в модуле, о доступе конкретного человека, о landing в ветке разработки, об отборе для этапа выпуска или о существующем артефакте Firefox для пользователей? У этих вопросов разные ответственные, записи и последствия.

Политика Module Ownership говорит, что владельцу модуля делегировано руководство работой модуля. Для кодового модуля его OK нужен, чтобы код был checked in в этот модуль. Владелец может назначать peers, которые также одобряют код, но обязан передать оценку собственного кода peer: сам себя он не проверяет. Он может запросить изменения, отклонить патч или отложить review, объяснив причину в соответствующем bug. Если спор не удаётся разрешить, предусмотрен путь участия структуры Module Ownership.

Это ограниченное техническое суждение, а не общий пропуск в репозитории и не решение о содержании версии Firefox. Mozilla отдельно описывает владельца модуля и владельца компонента Bugzilla: один отвечает за направление и review кода, другой является получателем отчётов по умолчанию. Иногда это один человек, но совпадение людей не сливает функции.

Доступ к commit — решение о доверии к человеку

Commit Access Policy отвечает на другой вопрос: какие разрешения нужны человеку для commit в разных репозиториях? В ней установлены уровни доступа и разные требования к поручительству. Для доступа к основному продукту нужны предусмотренные поручительства соответствующих владельцев модулей или peers либо Tree Sheriffs. При этом сама политика отмечает, что социальные меры контроля могут не позволить человеку делать check-in в некоторые деревья.

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

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

Landing не является обещанием поставки

Landing связывает изменение с ревизией, репозиторием и веткой. Это существенное свидетельство, но не доказательство того, что изменение получит пользователь. Руководство по выпуску Firefox описывает разные ветки firefox-main, firefox-beta и firefox-release, а также каналы Nightly, Beta и Release. Переход между ними имеет собственный ритм и условия; код должен сначала попасть в main, прежде чем его можно будет uplift в beta.

У Release Drivers иная функция: управление проектом для этапных выпусков, указание важных для выпуска исправлений и решения по управлению деревьями. Review модуля может открыть путь к следующей передаче, но сам по себе не выбирает содержимое публичного канала. И приоритет выпуска не переписывает техническое суждение модуля. Dot release зависит от достаточно важного driver, а не возникает автоматически из предыдущего OK.

Сделать передачи проверяемыми

Для значимого публичного утверждения компактная запись должна начать со стабильного идентификатора изменения и модуля. Затем указать роль owner или peer, выполнившего review, публичную запись review и дату. Если заявляется доступ, следует указать применимый уровень или разрешённый путь, не раскрывая ненужные персональные данные. После этого — вошедшую ревизию, репозиторий и ветку. Для утверждения о выпуске требуются целевой канал или ветка, свидетельство отбора, публичный артефакт и дата.

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

Sources

  1. Mozilla Modules and Module Owners
  2. Mozilla Commit Access Policy
  3. Becoming A Mozilla Committer
  4. Mozilla Roles and Leadership
  5. Pocket Guide: Shipping Firefox
  6. Lu Heng, The Multi-Stakeholder Mirage
  7. Lu Heng, Running-Code Primacy