Hi all,
so, as far as I can tell, the consensus is to keep it "simple", and
there are (again, as far as I can tell) four possible policies. Let me
know if I have captured everyone's wishes.
Since I moved this over to -dev, just a quick summary: We're discussing
review and commit policies for ATS going forward. There are three main
"concepts":
* No review required for commits
* Review Then Commit (RTC)
* Commit Then Review (CTR)
Here are the four policies I'd like to propose, and which we'll vote on
later (don't vote yet please!):
1. RTC for everything except trivial changes (e.g. comments etc.).
This has effectively been the policy so far.
2. CTR for trunk, RTC for all release ("stable") branches.
3. A more relaxed policy, with RTC for all release branches, and RTC
for trunk, except
* Trivial code changes (comments, indentations, release notes
etc.) - No Review
* Small code changes (few lines of code) - CTR
* Large changes, architectural changes, or security fixes - RTC
4. Like #4, but even more relaxed, release branches are still RTC:,
and RTS for trunk, except
* Trivial code changes (comments, indentations, release notes
etc.) - No Review
* Small code changes - CTR is optional, but changes should be
possible to review in ~5 minutes.
* Small code changes that would take longer than 5 minutes to
review - CTR
* Large changes, architectural changes, or security fixes - RTC
Two thoughts / conditions (not up for votes, but should be documented on
our Wiki page):
1. Security fixes should be reviewed in private, with assigned CVEs
etc., before code is committed to the repository. This means
security patches should *not* be posted on Jira tickets and
discussed there.
2. For large, disruptive changes, development on a branch is
encouraged. This would not be the old concept of a "dev" branch,
but a branch specific to a particular change / feature that would
otherwise risk making trunk very unstable during development.
