diff options
author | Konstantin Boudnik <cos@apache.org> | 2015-11-24 12:21:57 -0800 |
---|---|---|
committer | Konstantin Boudnik <cos@apache.org> | 2015-11-24 12:22:36 -0800 |
commit | 5d7b6e07223607f384b5092e61a682e65abab707 (patch) | |
tree | cfe6912fc88deebac4901ac296e9d66ae039adcd /README.md | |
parent | 5545eb599ab9549cd8b348c36bc401452236109c (diff) |
BIGTOP-2158. Update README.md to reflect the acceptance of CTR model
Diffstat (limited to 'README.md')
-rw-r--r-- | README.md | 17 |
1 files changed, 8 insertions, 9 deletions
@@ -55,13 +55,11 @@ There are lots of ways to contribute. People with different expertise can help Also, opening [JIRA's](https://issues.apache.org/jira/browse/BIGTOP) and getting started by posting on the mailing list is helpful. -CTR model trial -=============== +CTR model +========= -As discussed on the dev@ list (http://bit.ly/1gLeArc) we are going into a trial -period of CTR model for Bigtop project. The trial will go into effect until -Dec, 5th, 2015 or for two months since the master CI disk space issues are resolve, -whichever comes first. The following rules will be used for the CTR process: +Bigtop supports Commit-Then-Review model of development. The following +rules will be used for the CTR process: * a committer can go ahead and commit the patch without mandatory review if felt confident in its quality (e.g. reasonable testing has been done locally; all compilations pass; RAT check is passed; the patch follows @@ -70,12 +68,13 @@ whichever comes first. The following rules will be used for the CTR process: there're doubts in the approach taken, design decision, or implementation details * a committer should keep an eye on the official CI builds at - http://ci.bigtop.apache.org:8080/view/Bigtop-trunk/ (Docker-Bigtop-* - builds) to make sure that committed changes haven't break anything. In + http://ci.bigtop.apache.org/view/Bigtop-trunk/ (Bigtop-trunk-packages builds) + to make sure that committed changes haven't break anything. In which case the committer should take a timely effort to resolve the issues and unblock the others in the community * any non-document patch is required to be opened for at least 24 hours for - review before it gets committed unless it has other committer's +1. + community feedback before it gets committed unless it has an explicit +1 + from another committer * any non-document patch needs to address all the comment and reach consensus before it gets committed without a +1 from other committers * there's no changes in the JIRA process, except as specified above |