From 2e77b32fb51e206f725124796ccee116b9d96c71 Mon Sep 17 00:00:00 2001
From: beorn7 <beorn@grafana.com>
Date: Wed, 5 Jun 2019 19:51:01 +0200
Subject: [PATCH] Further clarification

Signed-off-by: beorn7 <beorn@grafana.com>
---
 RELEASE.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/RELEASE.md b/RELEASE.md
index a28530476..2eaf656c8 100644
--- a/RELEASE.md
+++ b/RELEASE.md
@@ -45,7 +45,7 @@ We maintain a separate branch for each minor release, named `release-<major>.<mi
 
 The usual flow is to merge new features and changes into the master branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into master from the latest release branch. The master branch should always contain all commits from the latest release branch. As long as master hasn't deviated from the release branch, new commits can also go to master, followed by merging master back into the release branch.
 
-If a bug fix got accidentally merged into master, cherry-pick commits have to be created in the latest release branch, which then have to be merged back into master. Try to avoid that situation.
+If a bug fix got accidentally merged into master after non-bug-fix changes in master, the bug-fix commits have to be cherry-picked into the release branch, which then have to be merged back into master. Try to avoid that situation.
 
 Maintaining the release branches for older minor releases happens on a best effort basis.