Merge pull request #27 from keystone-enclave/dev

Change CONTRIBUTING.md

CONTRIBUTING.md

@@ -22,7 +22,6 @@ Please update the documentation if needed.
 **Snapshot** - A certain version on any branch, having a unique commit hash. A snapshot is 1-1 mapped to a commit hash.
 
 **Healthy Snapshot** - If a snapshot is not broken and works well with the up-to-date documentation, the snapshot is told to be *healthy*. However, it does not mean that the branch has no bug or security hole. There's no such snapshot.
-Healthiness is different from *stability*. See [How To Release](# How to Release) to see what is a *stable* version.
 
 **Healthy Branch** - If the latest snapshot of a branch is healthy, the branch is told to be healthy.
 
@@ -41,28 +40,31 @@ These branches should be deleted after merge.
 ### Maintaining Healthiness
 
 The snapshot is healty if:
-(1) All documents are up to date and agree with the current code
+(1) All documents are up-to-date and agree with the current code
 (2) All tests succeed
-(3) All submodules points to `master` of themselves
 
 1. `master` must always be *healthy*
-2. No direct commits allowed to `master`. `master` can be updated only by merging healthy `dev`.
+2. No direct commits allowed to `master`. `master` can be updated only by PR-ing healthy `dev`.
 3. `dev` can be unhealthy, but should be healthy before being merged into `master`
 Ideally `dev` should not stay unhealthy more than a few days.
 
-### Rules for Submodules
+### Rules for Submodules (`sdk` and `runtime`)
 
-1. Submodules in `keystone:master` should always point to commits on `<submodule>:master`.
-2. Submodules in `keystone:dev` should point to commits on `<submodule>:master` before being merged into `master`.
-3. `master` of submodules should be always healthy (it compiles well and passes some basic tests).
-4. submodules can also have `dev-<name of task>` branch for each open task. 
+For `sdk` and `runtime`, `<submodule>:master` means the `master` branch of each submodule.
+For `riscv-pk` and `busybear-linux`, use `keystone` instead of `master` as the master branch.
+This is because those repositories are the mirrors of some upstream repos.
+We want to keep `master` clean so that we can pull the upstream changes into `master`.
+
+1. The submodules in `keystone:master` and `keystone:dev` should always point to the commits on `<submodule>:master`.
+2. `master` of submodules should be always healthy (it compiles well and passes some basic tests).
+3. The submodules can also have `dev-<name of task>` branch for each open task. 
 These kind of branches should be deleted right after merge
 
 # How to Release
 
 ### Version Number
 
-A version number consists of `major` and `minor`. For example, `1.14` means that the major is 1 and the minor is 14.
+A version number consists of two positive integers: `major` and `minor`. For example, `1.14` means that the major is 1 and the minor is 14.
 The numbers increase on each *major release* or *minor release* respectively. 
 
 ### Releasing