Hi everyone,
up for vote is to decide on a policy for RTC ("Review-Then-Commit") vs
CTR ("Commit-Then-Review). Attached below are four options, ranging from
the most conservative to the most liberal. Please vote on this, I urge
everyone working with the source to vote within 72 hours. If you are
only going to vote on one thing, vote on this one. :)
Vote on the following alternatives
-----------------------------------
[ ] RTC for everything except trivial changes (e.g. comments).
[ ] RTC for everything, except very small changes which are CTR.
[ ] RTC for everything, except code which would take ~5 minutes to
review. Such changes are CTR.
[ ] CTR for trunk, RTC for all release branches.
(note that all options implies RTC for all release branches, that is not
up for vote).
Not up for vote are a few things that we've already decided, and/or just
makes common sense. This will be documented in the Wiki page, and include:
* All commits should have a Jira ticket. One Jira ticket can be used for
multiple commits (such umbrella bugs could be used for large code
cleanup projects, the RAT bug is a good example).
* Reviews (if applicable) should be done in a timely manner (7 days).
* Anyone can review any bug.
* People can sign up as "module reviewers", in areas where they have
interest and/or expertise. We'll keep a Wiki page with such domain
expertise.
* Significant code changes that could be disruptive on trunk should be
developed on a branch. The branch name will reflect the feature / change
accordingly.
* Large code changes, additions, architectural designs should be
discussed on mailing lists, IRC and Wiki / HTML pages.
* Security bugs and fixes should not be discussed or posted on public
forums.
* CTR implies lazy consensus.
(If anyone would like to change any of these, please make a separate
proposal).
Looking forward to lots of votes,
-- leif
