chore(docs): explain the process for merging changes to master

Closes #3566
This commit is contained in:
Alex Eagle 2015-08-10 11:45:50 -07:00 committed by Alex Eagle
parent 903a0f0513
commit 561066f899
2 changed files with 35 additions and 4 deletions

31
COMMITTER.md Normal file
View File

@ -0,0 +1,31 @@
# Pushing changes into the Angular 2 tree
Please see [Using git with Angular repositories](https://docs.google.com/document/d/1h8nijFSaa1jG_UE8v4WP7glh5qOUXnYtAtJh_gwOQHI/edit)
for details about how we maintain a linear commit history, and the rules for committing.
As a contributor, just read the instructions in [CONTRIBUTING.md](CONTRIBUTING.md) and send a pull request.
Someone with committer access will do the rest.
## The `PR: merge` label and `presubmit-*` branches
We have automated the process for merging pull requests into master. Our goal is to minimize the disruption for
Angular committers and also prevent breakages on master.
When a PR is ready to merge, a project member in the CoreTeamMember list (see below) can add the special label,
`PR: merge`.
A robot running as [mary-poppins](https://github.com/mary-poppins)
is notified that the label was added by an authorized person,
and will create a new branch in the angular project, using the convention `presubmit-{username}-pr-{number}`.
(Note: if the automation fails, committers can instead push the commits to a branch following this naming scheme.)
When a Travis build succeeds for a presubmit branch named following the convention,
Travis will re-base the commits, merge to master, and close the PR automatically.
Finally, after merge `mary-poppins` removes the presubmit branch.
## Administration
The list of users who can trigger a merge by adding the label is stored in our appengine app datastore.
Edit the contents of the [CoreTeamMember Table](
https://console.developers.google.com/project/angular2-automation/datastore/query?queryType=KindQuery&namespace=&kind=CoreTeamMember)

View File

@ -44,13 +44,13 @@ closing or reviewing PRs is a top priority ahead of other ongoing work.
Every triaged PR must have a `pr_action` label assigned to it and an assignee: Every triaged PR must have a `pr_action` label assigned to it and an assignee:
* `pr_action: review` -- work is complete and comment is needed from the assignee.
* `pr_action: cleanup` -- more work is needed from the current assignee. * `pr_action: cleanup` -- more work is needed from the current assignee.
* `pr_action: discuss` -- discussion is needed, to be led by the current assignee. * `pr_action: discuss` -- discussion is needed, to be led by the current assignee.
* `pr_action: merge` -- OK to merge this as soon as tests are green, `pr_state: LGTM`, and `CLA: * `pr_action: merge` -- the PR should be merged. Add this to a PR when you would like to
yes` are true. assignee (or anyone else) can merge. trigger automatic merging following a successful build. This is described in [COMMITTER.md](COMMITTER.md).
* `pr_action: review` -- work is complete and comment is needed from the assignee.
In addition, PRs can have the following states: In addition, PRs can have the following states:
* `pr_state: LGTM` -- PR may have outstanding changes but does not require further review. * `pr_state: LGTM` -- PR may have outstanding changes but does not require further review.
* `pr_state: WIP` -- PR is experimental or rapidly changing. Not ready for review or triage. * `pr_state: WIP` -- PR is experimental or rapidly changing. Not ready for review or triage.