Page History

...

Code Change Governing Policy

Apache Knox follows the Commit-Then-Review policy as defined in: http://www.apache.org/foundation/glossary.html

Commit-Then-Review

(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code changes which permits developers to make changes at will, with the possibility of being retroactively vetoed. C-T-R is an application of decision making through lazy consensus. The C-T-R model is useful in rapid-prototyping environments, but because of the lack of mandatory review it may permit more bugs through in daily practice than the R-T-C alternative. Compare R-T-C , and see the description of the voting process.

Acknowledging the potential negative aspects of not mandating a review for every commit, we have a short set of guidelines and a notification mechanism for ensuring the rapid development that CTR affords the community while providing communication and attention to review comments which are all important to the Knox community.

The following guidelines are prescribed for committers on the Apache Knox project and should be considered for each change commit:

Guidelines

1. For any patches that make fundamental, architectural or security related changes - committers should solicit feedback on the design and document it clearly in an document attached to JIRA or wiki linked to from the JIRA
2. For any patches that are extensions to existing patterns for features - such as adding new service API support, the committer may commit freely - given sufficient tests and documentation (to the committer's discretion)
3. For any patches that are simple bug fixes, the committer may commit freely

Notification

In order to draw attention to review topics the use of the [REVIEW] tag in an email subject will be used for:

1. Reviews from community members post commit - we will use an email with a [REVIEW] tag to indicate that comments are being provided for a merged change and that it needs attention. Committers must review such comments and assess whether they should manifest in:
   1. New JIRAs to address the review comments
   2. A veto discussion and revert upon justification - see the veto process definition
   3. Further documentation is needed
   4. Any combination of above
2. The [REVIEW] tag may also be used by committers or any contributor in order to solicit feedback on design or technical details from the community at large - see guideline #1 above.

Casual Browsing

https://git-wip-us.apache.org/repos/asf?p=knox.git

...

If you have commit access on the Apache repository then you will not be applying patches in the manner described in the reviewer workflow. Instead, once your patch has been reviewed is ready, you will check it in yourself as follows:

...

4. Run the tests. Should always rebase before testing before prior to submitting a patch.

ant verify

5. Create a patch, if desired

git reset --soft origin/master
git commit -am "KNOX-nnn: <short, meaningful message>"
git format-patch origin/master --stdout > KNOX-nnn.patch

6. Post the change patch file to JIRA and optionally get it reviewed.

7. Push the change back to Apache. Pick one of the following:

...

This sets up the remote alias "origin" automatically which refers back to the Apache repo.
2. Create a new github repository on your github account to use for stashing changes. There are various ways to do this, I just forked the Apache Knox repo (https://github.com/apache/knox) which creates a repo https://github.com/<github_username>/knox
3. Add an alias on your local repository to github to avoid typing:

...