Re: [discuss] RTC vs CTR vs no-review

[Leif Hedstrom <zw...@apache.org>]

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.