Commit 5f3bb097 authored by intrigeri's avatar intrigeri

Document expectations for developers to communicate with the RM (#17571)

parent bf356c9e
......@@ -228,6 +228,8 @@ Collective process
- [[UX designers|contribute/working_together/roles/ux]]
- [[Verification extension
- Interfaces between roles and teams
- [[Developers and Release Managers|contribute/working_together/interfaces/developers_and_release_managers]]
- Roles for sponsor deliverables:
- [[Team manager|contribute/working_together/roles/sponsor_deliverables/team_manager]]
- [[Worker|contribute/working_together/roles/sponsor_deliverables/worker]]
......@@ -42,3 +42,8 @@ identify the root cause of it to a recent commit, fix it if you wish,
but don't let it disturb you otherwise: just revert the faulty commit
and inform the other developers on [[|about/contact#tails-dev]] so that the author knows
s/he needs to fix his/her stuff before reapplying it at a later point.
## Coordinate major changes and freeze exceptions with Release Managers
See the coordination guidelines [[for developers with Release
[[!meta title="Interfaces between roles and teams"]]
[[!map pages="contribute/working_together/interfaces/*"]]
[[!meta title="Interface between developers and Release Managers"]]
Code changes merged into our release branches (`stable`, `testing`, `devel`) may
impact the [[Release
Managers|contribute/working_together/roles/release_manager]]' work: for example,
the Release Manager on duty is on the frontline when manual testing done during
the release process identifies critical breakage at the last minute before we
publish a new version of Tails. This can disrupt the release schedule and lead
to highly stressful situations.
These guidelines are meant to decrease the risk of seeing such problems happen.
[[!toc levels=2]]
# Changes that may impact automatic upgrades
For changes that may impact automatic upgrades, the responsible developers MUST
put the Release Managers into the loop in advance, way before the code is
merged. This allows the Release Managers to:
- Raise any concerns they may have about the design or implementation
of the proposed changes.
- Propose extra manual tests that could be done ahead of merging
and/or during the manual testing session of the release process,
in order to build confidence in the proposed changes.
- Make developers benefit from an independent "What can possibly go
wrong?" brainstorming.
# During a code freeze
We sometimes [[freeze|contribute/release_schedule]] one of our release branches,
in order to stabilize it before a release.
During such a code freeze, developers MUST notify the Release Manager on duty
about freeze exceptions they intend to propose or merge. And then:
- If the proposed changes may impact automatic upgrades, as a developer, ensure
you get feedback from the Release Manager on duty, before you apply
a freeze exception.
- Else, that is in the general case, as a developer you don't need to block on
the Release Manager's feedback before you apply the freeze exception.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment