Document expectations for developers to communicate with the RM
We discussed this topic with kibi in the last 2-3 months, in part of the
post-mortem of the 4.2.* mess (#15281 (closed)).
Here’s what we agreed on:
For changes that may impact automatic upgrades, the responsible developers MUST put the RM into the loop in advance (way before the code is merged). Then the RM can:
- Raise any concerns
- Propose extra manual tests that would help build confidence in the changes
- Make developers benefit from an independent “What can possibly go wrong?” brainstorming
Also, during a code freeze, developers MUST let the RM know about freeze exceptions they intend to propose or merge:
- In the general case, once the RM has been notified, there’s no need for the developers to block on the RM’s feedback before proceeding.
- For changes that may impact automatic upgrades, it’s very important to get feedback from the RM before making a freeze exception.
I’ll document these expectations somewhere so that developers are aware of them and can look them up later.