In the release planning 2023 thread, there is also discussion about how to decide code is ready to be merged. The following are some guidelines I’m proposing that go along with having a master and stable branch.
Master items.
- Must compile on all system where github buiud tools are working.
- Must pass unit tests on developer and reviewers computer.
- Passes unit tests in other places if they exist.
- Request explains how tests already cover the changes, adds tests to cover or explains why it’s not relevant.
- Is reviewed and approvet by one other developer with commit rights.
This does have some overhead, but I believe over time quickly adds the following benefits.
- Increases test coverage and overall confidence in the tool.
- Enables at least one core developer to understand the changes being presented. Even if they also ask for more input.
- Barriers to entry are clear and a pull request submitter can meet most at submission time. Reviewer has a minimum set of tasks to check and also can apply wisdom if they are the best available to agree to the change.
It may be required to address some issues around tests for this to be applied. My experience is that is better to start with less tests that all pass than to keep flaky tests in operation when completing a transition to this workflow.
In cases of single committer, either they go with no review, or get review of someone who does not have commit rights.
Feedback on this?