You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The Different Development Modes

This page is definitely in-progress.

Commit-Then-Review

C-T-R mode is short for "[http://incubator.apache.org/learn/glossary.html#CommitThenReview Commit-then-Review]". This is the standard development mode that we are in. It means that developers may commit patches to the development tree without the code/rules/etc being reviewed by other developers first. Typically HEAD/trunk is in C-T-R mode until a new release is approaching. We then switch to R-T-C mode (see below) for the final development up to release.

Review-Then-Commit

R-T-C mode is short for "[http://incubator.apache.org/learn/glossary.html#ReviewThenCommit Review-then-Commit]". Non-trivial patches (see below) must be reviewed by developers and need consensus approval before being committed into the development tree. This is typically done by opening a Bugzilla ticket, setting the [TargetMilestone] to the correct release of the tree, attaching the suggested patch to the ticket via the web interface, and putting the ticket in "review" status (indicated by [review] as a prefix to the ticket summary).

The patch is then [http://incubator.apache.org/learn/voting.html voted] upon, and if gets a [http://incubator.apache.org/learn/glossary.html#ConsensusApproval consensus approval] and is not [http://incubator.apache.org/learn/glossary.html#Veto vetoed], can be applied to the tree. Votes should generally be permitted to run for at least 24 hours to provide an opportunity for all concerned persons to participate regardless of their geographic locations. "Consensus approval" refers to a vote which has completed with at least three binding +1 votes and no -1 vetos. The author of a patch is allowed to vote as long as they're a committer.

Non-trivial patches include:

  • documentation
  • finishing off pre-existing T_ tests
  • non-controversial non-semantic style changes (fixing indentation, adding comments, but not actual code)
  • very simple, non-controversial, and absolutely safe bug fixes (i.e.: removing repetitive my() enclosing sections)

(TheoVanDinter)

  • No labels