Merge branch 'master' into mmonaco/gitlab-ce-api-user-noconfirm

Conflicts:
	lib/api/users.rb

5 files changed, 272 insertions, 242 deletions

diff --git a/doc/release/howto_rc1.md b/doc/release/howto_rc1.md
new file mode 100644
index 00000000000..c4156d25d5f
--- /dev/null
+++ b/doc/release/howto_rc1.md
@@ -0,0 +1,74 @@
+# How to create RC1
+
+The RC1 release comes with the task to update the installation and upgrade docs. Be mindful that there might already be merge requests for this on GitLab or GitHub.
+
+### 1. Update the installation guide
+
+1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
+1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782)
+1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794)
+1. There might be other changes. Ask around.
+
+### 2. Create update guides
+
+[Follow this guide](howto_update_guides.md) to create update guides.
+
+### 3. Code quality indicators
+
+Make sure the code quality indicators are green / good.
+
+- [![Build status](http://ci.gitlab.org/projects/1/status.png?ref=master)](http://ci.gitlab.org/projects/1?ref=master) on ci.gitlab.org (master branch)
+
+- [![Build Status](https://semaphoreapp.com/api/v1/projects/2f1a5809-418b-4cc2-a1f4-819607579fe7/243338/badge.png)](https://semaphoreapp.com/gitlabhq/gitlabhq) (master branch)
+
+- [![Code Climate](https://codeclimate.com/github/gitlabhq/gitlabhq.png)](https://codeclimate.com/github/gitlabhq/gitlabhq)
+
+- [![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available)
+
+- [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
+
+### 4. Run release tool for CE and EE
+
+**Make sure EE `master` has latest changes from CE `master`**
+
+Get release tools
+
+```
+git clone git@dev.gitlab.org:gitlab/release-tools.git
+cd release-tools
+```
+
+Release candidate creates stable branch from master. 
+So we need to sync master branch between all CE remotes. Also do same for EE.
+
+```
+bundle exec rake sync
+```
+
+Create release candidate and stable branch:
+
+```
+bundle exec rake release["x.x.0.rc1"]
+```
+
+Now developers can use master for merging new features.
+So you should use stable branch for future code changes related to release.
+
+
+### 5. Release GitLab CI RC1
+
+Add to your local `gitlab-ci/.git/config`:
+
+```
+[remote "public"]
+    url = none
+    pushurl = git@dev.gitlab.org:gitlab/gitlab-ci.git
+    pushurl = git@gitlab.com:gitlab-org/gitlab-ci.git
+    pushurl = git@github.com:gitlabhq/gitlab-ci.git
+```
+
+* Create a stable branch `x-y-stable`
+* Bump VERSION to `x.y.0.rc1`
+* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)"`
+* `git push public x-y-stable v$(cat VERSION)`
+
diff --git a/doc/release/howto_update_guides.md b/doc/release/howto_update_guides.md
new file mode 100644
index 00000000000..23d0959c33d
--- /dev/null
+++ b/doc/release/howto_update_guides.md
@@ -0,0 +1,55 @@
+# Create update guides
+
+1. Create: CE update guide from previous version. Like `7.3-to-7.4.md`
+1. Create: CE to EE update guide in EE repository for latest version.
+1. Update: `6.x-or-7.x-to-7.x.md` to latest version.
+1. Create: CI update guide from previous version
+
+It's best to copy paste the previous guide and make changes where necessary.
+The typical steps are listed below with any points you should specifically look at.
+
+#### 0. Any major changes?
+
+List any major changes here, so the user is aware of them before starting to upgrade. For instance:
+
+- Database updates
+- Web server changes
+- File structure changes
+
+#### 1. Stop server
+
+#### 2. Make backup
+
+#### 3. Do users need to update dependencies like `git`?
+
+- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release.
+
+- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release.
+
+#### 4. Get latest code
+
+#### 5. Does GitLab shell need to be updated?
+
+#### 6. Install libs, migrations, etc.
+
+#### 7. Any config files updated since last release?
+
+Check if any of these changed since last release:
+
+- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab)
+- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl)
+- <https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example>
+- [config/gitlab.yml.example](/config/gitlab.yml.example)
+- [config/unicorn.rb.example](/config/unicorn.rb.example)
+- [config/database.yml.mysql](/config/database.yml.mysql)
+- [config/database.yml.postgresql](/config/database.yml.postgresql)
+- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example)
+- [config/resque.yml.example](/config/resque.yml.example)
+
+#### 8. Need to update init script?
+
+Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab)
+
+#### 9. Start application
+
+#### 10. Check application status
diff --git a/doc/release/monthly.md b/doc/release/monthly.md
index 386c19c0fe0..c9e6d3426bc 100644
--- a/doc/release/monthly.md
+++ b/doc/release/monthly.md
@@ -1,190 +1,116 @@
 # Monthly Release
 
-NOTE: This is a guide for GitLab developers.
+NOTE: This is a guide used by the GitLab B.V. developers.
 
-# **7 workdays before release - Code Freeze & Release Manager**
+It starts 7 working days before the release.
+The release manager doesn't have to perform all the work but must ensure someone is assigned.
+The current release manager must schedule the appointment of the next release manager.
+The new release manager should create overall issue to track the progress.
 
-### **1. Stop merging in code, except for important bug fixes**
+## Release Manager
 
-### **2. Release Manager**
+A release manager is selected that coordinates all releases the coming month, including the patch releases for previous releases.
+The release manager has to make sure all the steps below are done and delegated where necessary.
+This person should also make sure this document is kept up to date and issues are created and updated.
 
-A release manager is selected that coordinates the entire release of this version. The release manager has to make sure all the steps below are done and delegated where necessary. This person should also make sure this document is kept up to date and issues are created and updated.
+## Take vacations into account
 
-### **3. Create an overall issue**
+The time is measured in weekdays to compensate for weekends. 
+Do everything on time to prevent problems due to rush jobs or too little testing time.
+Make sure that you take into account any vacations of maintainers.
+If the release is falling behind immediately warn the team.
+
+## Create an overall issue and follow it
 
 Create issue for GitLab CE project(internal). Name it "Release x.x.x" for easier searching.
 Replace the dates with actual dates based on the number of workdays before the release.
+All steps from issue template are explained below
 
 ```
-Xth:
-
-* Update the changelog (#LINK)
-* Triage the omnibus-gitlab milestone
-
-Xth:
-
-* Merge CE in to EE (#LINK)
-* Close the omnibus-gitlab milestone
-
-Xth:
-
-* Create x.x.0.rc1 (#LINK)
-* Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package)
-
-Xth:
-
-* Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package)
-* Regression issue and tweet about rc1 (#LINK)
-* Start blog post (#LINK)
-
-Xth:
-
-* Do QA and fix anything coming out of it (#LINK)
-
-22nd:
-
-* Release CE and EE (#LINK)
-
-Xth:
-
-* * Deploy to GitLab.com (#LINK)
-
-```
-
-### **4. Update changelog**
-
-Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is asked if there is anything missing.
-
-### **5. Take weekend and vacations into account**
-
-Ensure that there is enough time to incorporate the findings of the release candidate, etc.
-
-# **6 workdays before release- Merge the CE into EE**
-
-Do this via a merge request.
+Xth: (7 working days before the 22nd)
 
-# **5 workdays before release - Create RC1**
+- [ ] Code freeze
+- [ ] Update the CE changelog (#LINK)
+- [ ] Update the EE changelog (#LINK)
+- [ ] Update the CI changelog (#LINK)
+- [ ] Triage the omnibus-gitlab milestone
 
-The RC1 release comes with the task to update the installation and upgrade docs. Be mindful that there might already be merge requests for this on GitLab or GitHub.
+Xth: (6 working days before the 22nd)
 
-### **1. Update the installation guide**
+- [ ] Merge CE master in to EE master via merge request (#LINK)
+- [ ] Create CE, EE, CI RC1 versions (#LINK)
+- [ ] Determine QA person and notify this person
 
-1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
-1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782)
-1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794)
-1. There might be other changes. Ask around.
+Xth: (5 working days before the 22nd)
 
-### **2. Create update guides**
+- [ ] Do QA and fix anything coming out of it (#LINK)
+- [ ] Close the omnibus-gitlab milestone
 
-1. Create: CE update guide from previous version. Like `7.3-to-7.4.md`
-1. Create: CE to EE update guide in EE repository for latest version.
-1. Update: `6.x-or-7.x-to-7.x.md` to latest version.
+Xth: (4 working days before the 22nd)
 
-It's best to copy paste the previous guide and make changes where necessary.
-The typical steps are listed below with any points you should specifically look at.
+- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package)
+- [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package)
 
-#### 0. Any major changes?
+Xth: (3 working days before the 22nd)
 
-List any major changes here, so the user is aware of them before starting to upgrade. For instance:
+- [ ] Create regression issues (CE, CI) (#LINK)
+- [ ] Tweet about rc1 (#LINK)
+- [ ] Prepare the blog post (#LINK)
 
-- Database updates
-- Web server changes
-- File structure changes
+Xth: (2 working days before the 22nd)
 
-#### 1. Make backup
+- [ ] Merge CE stable branch into EE stable branch
+- [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago)
 
-#### 2. Stop server
+Xth: (1 working day before the 22nd)
 
-#### 3. Do users need to update dependencies like `git`?
+- [ ] Create CE, EE, CI stable versions (#LINK)
+- [ ] Create Omnibus tags and build packages
+- [ ] Update GitLab.com with the stable version (#LINK)
 
-- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release.
-
-- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release.
-
-#### 4. Get latest code
-
-#### 5. Does GitLab shell need to be updated?
-
-#### 6. Install libs, migrations, etc.
-
-#### 7. Any config files updated since last release?
-
-Check if any of these changed since last release:
-
-- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab)
-- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl)
-- <https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example>
-- [config/gitlab.yml.example](/config/gitlab.yml.example)
-- [config/unicorn.rb.example](/config/unicorn.rb.example)
-- [config/database.yml.mysql](/config/database.yml.mysql)
-- [config/database.yml.postgresql](/config/database.yml.postgresql)
-- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example)
-- [config/resque.yml.example](/config/resque.yml.example)
-
-#### 8. Need to update init script?
-
-Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab)
-
-#### 9. Start application
-
-#### 10. Check application status
+22nd:
 
-### **3. Code quality indicators**
+- [ ] Release CE, EE and CI (#LINK)
 
-Make sure the code quality indicators are green / good.
+```
 
-- [![Build status](http://ci.gitlab.org/projects/1/status.png?ref=master)](http://ci.gitlab.org/projects/1?ref=master) on ci.gitlab.org (master branch)
+- - -
 
-- [![Build Status](https://semaphoreapp.com/api/v1/projects/2f1a5809-418b-4cc2-a1f4-819607579fe7/243338/badge.png)](https://semaphoreapp.com/gitlabhq/gitlabhq) (master branch)
+## Code Freeze
 
-- [![Code Climate](https://codeclimate.com/github/gitlabhq/gitlabhq.png)](https://codeclimate.com/github/gitlabhq/gitlabhq)
+Stop merging code in master, except for important bug fixes
 
-- [![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available)
+## Update changelog
 
-- [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
+Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is
+asked if there is anything missing.
 
-### **4. Set VERSION**
+There are three changelogs that need to be updated: CE, EE and CI.
 
-Change version in VERSION to `x.x.0.rc1`.
+## Create RC1 (CE, EE, CI)
 
-### **5. Tag**
+[Follow this How-to guide](howto_rc1.md) to create RC1.
 
-Create an annotated tag that points to the version change commit:
+## Prepare CHANGELOG for next release
 
-```
-git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
-```
+Once the stable branches have been created, update the CHANGELOG in `master` with the upcoming version.
 
-Tags should be created for both GitLab CE and GitLab EE. Don't forget to push tags to all remotes.
+## QA
 
-```
-git push remote_name vx.x.0.rc1
-```
-
-### **6. Create stable branches**
-
-For GitLab EE, append `-ee` to the branch.
-
-`x-x-stable-ee`
-
-```
-git checkout master
-git pull
-git checkout -b x-x-stable
-git push <remote> x-x-stable
-```
+Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress.
 
-Now developers can use master for merging new features.
-So you should use stable branch for future code chages related to release.
+Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md).
 
+**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue.
 
-# **4 workdays before release - Release RC1**
+#### Fix anything coming out of the QA
 
-### **1. Determine QA person
+Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice.
 
-Notify person of QA day.
+**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted,
+create an issue about it in order to discuss the next steps after the release.
 
-### **2. Update GitLab.com**
+## Update GitLab.com with RC1
 
 Merge the RC1 EE code into GitLab.com.
 Once the build is green, create a package.
@@ -192,20 +118,7 @@ If there are big database migrations consider testing them with the production d
 Try to deploy in the morning.
 It is important to do this as soon as possible, so we can catch any errors before we release the full version.
 
-### **3. Prepare the blog post**
-
-- Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out.
-- Check the changelog of CE and EE for important changes.
-- Create a WIP MR for the blog post
-- Ask Dmitriy to add screenshots to the WIP MR.
-- Decide with team who will be the MVP user. 
-- Create WIP MR for adding MVP to MVP page on website
-- Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
-- Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master)
-- Assign to one reviewer who will fix spelling issues by editing the branch (can use the online editor)
-- After the reviewer is finished the whole team will be mentioned to give their suggestions via line comments
-
-### **4. Create a regressions issue**
+## Create a regressions issue
 
 On [the GitLab CE issue tracker on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/) create an issue titled "GitLab X.X regressions" add the following text:
 
@@ -216,117 +129,78 @@ The release manager will comment here about the plans for patch releases.
 
 Assign the issue to the release manager and /cc all the core-team members active on the issue tracker. If there are any known bugs in the release add them immediately.
 
-### **4. Tweet**
+## Tweet about RC1
 
 Tweet about the RC release:
 
 > GitLab x.x.0.rc1 is out. This release candidate is only suitable for testing. Please link regressions issues from LINK_TO_REGRESSION_ISSUE
 
-# **1 workdays before release - Preparation**
-
-### **1. Pre QA merge**
-
-Merge CE into EE before doing the QA.
-
-### **2. QA**
+## Prepare the blog post
 
-Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress.
-
-Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md).
-
-**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue.
-
-### **3. Fix anything coming out of the QA**
-
-Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice.
-
-**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted,
-create an issue about it in order to discuss the next steps after the release.
+1. Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out.
+1. Make sure the blog post contains information about the GitLab CI release.
+1. Check the changelog of CE and EE for important changes.
+1. Also check the CI changelog
+1. Add a proposed tweet text to the blog post WIP MR description.
+1. Create a WIP MR for the blog post
+1. Ask Dmitriy to add screenshots to the WIP MR.
+1. Decide with team who will be the MVP user. 
+1. Create WIP MR for adding MVP to MVP page on website
+1. Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
+1. Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master)
+1. Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor)
+1. Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)'
 
-# **22nd - Release CE and EE**
+## Create CE, EE, CI stable versions
 
-For GitLab EE, append `-ee` to the branches and tags.
+Get release tools
 
-`x-x-stable-ee`
-
-`v.x.x.0-ee`
+```
+git clone git@dev.gitlab.org:gitlab/release-tools.git
+cd release-tools
+```
 
-Note: Merge CE into EE if needed.
+Bump version, create release tag and push to remotes:
 
-### **1. Set VERSION to x.x.x and push**
+```
+bundle exec rake release["x.x.0"]
+```
 
-- Change the GITLAB_SHELL_VERSION file in `master` of the CE repository if the version changed.
-- Change the GITLAB_SHELL_VERSION file in `master` of the EE repository if the version changed.
-- Change the VERSION file in `master` branch of the CE repository and commit and push to origin.
-- Change the VERSION file in `master` branch of the EE repository and commit and push to origin.
+Also perform these steps for GitLab CI:
 
-### **2. Update installation.md**
+1. bump version in the stable branch
+1. create annotated tag
+1. push the stable branch and the annotated tag to the public repositories
 
 Update [installation.md](/doc/install/installation.md) to the newest version in master.
 
-### **3. Push latest changes from x-x-stable branch to dev.gitlab.org**
 
-```
-git checkout -b x-x-stable
-git push origin x-x-stable
-```
-
-### **4. Build the Omnibus packages**
+## Create Omnibus tags and build packages
 
 Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md).
 This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase.
 
-### **5. Create annotated tag vx.x.x**
-
-In `x-x-stable` branch check for the SHA-1 of the commit with VERSION file changed. Tag that commit,
-
-```
-git tag -a vx.x.0 -m 'Version x.x.0' xxxxx
-```
-
-where `xxxxx` is SHA-1.
-
-### **6. Push the tag and x-x-stable branch to the remotes**
 
-For GitLab CE, push to dev, GitLab.com and GitHub.
+## Release CE, EE and CI
 
-For GitLab EE, push to the subscribers repo.
-
-Make sure the branch is marked 'protected' on each of the remotes you pushed to.
-
-```
-git push <remote> x-x-stable(-ee)
-git push <remote> vx.x.0
-```
-
-### **7. Publish packages for new release**
+__1. Publish packages for new release__
 
 Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository.
 
-### **8. Publish blog for new release**
+__2. Publish blog for new release__
 
+Doublecheck the everyone has been mentioned in the blog post.
 Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.
 
-### **9. Tweet to blog**
+__3. Tweet to blog__
 
 Send out a tweet to share the good news with the world.
 List the most important features and link to the blog post.
 
-Proposed tweet for CE "GitLab X.X is released! It brings *** <link-to-blogpost>"
-
-# **1 workday after release - Update GitLab.com**
-
-Update GitLab.com from RC1 to the released package.
-
-# **25th - Release GitLab CI**
+Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE &lt;link-to-blog-post&gt; #gitlab"
 
-- Create the update guid `doc/x.x-to-x.x.md`.
-- Update CHANGELOG
-- Bump version
-- Create annotated tags `git tag -a vx.x.0 -m 'Version x.x.0' xxxxx`
-- Create stable branch `x-x-stable`
-- Create GitHub release post
-- Post to blog about release
-- Post to twitter
+Consider creating a post on Hacker News.
 
+## Update GitLab.com with the stable version
 
+- Deploy the package (should not need downtime because of the small difference with RC1)
diff --git a/doc/release/patch.md b/doc/release/patch.md
index 5d2fa053cac..d8bb4aef0e2 100644
--- a/doc/release/patch.md
+++ b/doc/release/patch.md
@@ -10,22 +10,47 @@ Otherwise include it in the monthly release and note there was a regression fix
 
 ## Release Procedure
 
+### Preparation
+
 1. Verify that the issue can be reproduced
 1. Note in the 'GitLab X.X regressions' that you will create a patch
 1. Create an issue on private GitLab development server
 1. Name the issue "Release X.X.X CE and X.X.X EE", this will make searching easier
 1. Fix the issue on a feature branch, do this on the private GitLab development server
+1. If it is a security issue, then assign it to the release manager and apply a 'security' label
 1. Consider creating and testing workarounds
 1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch
-1. In a separate commit in the stable branch update the CHANGELOG
-1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X"
-1. In a separate commit in the stable branch update the VERSION
-1. Create an annotated tag vX.X.X for CE and another patch release for EE `git tag -a vx.x.x -m 'Version x.x.x'`
 1. Make sure that the build has passed and all tests are passing
-1. Push the code and the tags to all the CE and EE repositories
-1. Apply the patch to GitLab Cloud and the private GitLab development server
+1. In a separate commit in the master branch update the CHANGELOG
+1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X"
+1. Merge CE stable branch into EE stable branch
+
+
+### Bump version
+
+Get release tools
+
+```
+git clone git@dev.gitlab.org:gitlab/release-tools.git
+cd release-tools
+```
+
+Bump version in stable branch, create release tag and push to remotes:
+
+```
+bundle exec rake release["x.x.x"]
+```
+
+Or if you need to release only EE:
+
+```
+CE=false be rake release['x.x.x']
+```
+
+### Release
+
 1. [Build new packages with the latest version](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md)
-1. Cherry-pick the changelog update back into master
+1. Apply the patch to GitLab.com and the private GitLab development server
 1. Create and publish a blog post
-1. Send tweets about the release from `@gitlabhq`, tweet should include the most important feature that the release is addressing and link to the blog post
+1. Send tweets about the release from `@gitlab`, tweet should include the most important feature that the release is addressing and link to the blog post
 1. Note in the 'GitLab X.X regressions' issue that the patch was published (CE only)
diff --git a/doc/release/security.md b/doc/release/security.md
index 79d23c02ea4..b67e0f37a04 100644
--- a/doc/release/security.md
+++ b/doc/release/security.md
@@ -14,11 +14,13 @@ Please report suspected security vulnerabilities in private to <support@gitlab.c
 
 1. Verify that the issue can be reproduced
 1. Acknowledge the issue to the researcher that disclosed it
+1. Inform the release manager that there needs to be a security release
 1. Do the steps from [patch release document](doc/release/patch.md), starting with "Create an issue on private GitLab development server"
+1. The MR with the security fix should get a 'security' label and be assigned to the release manager
+1. Build the package for GitLab.com and do a deploy
 1. Create feature branches for the blog post on GitLab.com and link them from the code branch
 1. Merge and publish the blog posts
 1. Send tweets about the release from `@gitlabhq`
-1. Send out an email to the 'GitLab Newsletter' mailing list on MailChimp (or the 'Subscribers' list if the security fix is for EE only)
 1. Send out an email to [the community google mailing list](https://groups.google.com/forum/#!forum/gitlabhq)
 1. Post a signed copy of our complete announcement to [oss-security](http://www.openwall.com/lists/oss-security/) and request a CVE number
 1. Add the security researcher to the [Security Researcher Acknowledgments list](http://about.gitlab.com/vulnerability-acknowledgements/)