Leif Hedstrom
2018-03-01 16:23:27 UTC
Hi all,
Sometimes, when a backport request from master to an LTS release has merge conflicts, the RM will ask for a new PR that fixes the merge conflicts. It’s important that we all do these the same way, so here’s the outline on how I think we should do these.
0) Make a branch off the LTS release you want to cherry-pick to (e.g. git checkout -b LeifBackport 7.1.x).
1) Run “cherry-pick -x abcd1234”, the -x here is critical.
2) Resolve the merge conflicts, but retain the commit Subject and message body as it was in the original commit.
3) Uncomment the section that specifies which files has merge conflicts. This would include that as part of the commit message, see the example below.
4) Make the PR on Github.
5) If you have permissions, please make an effort to set the same Labels, Assignees etc. Set the reviewer to the RM for the LTS that you are backporting to. Add the Backport label as well, to make it clear that this was a backport of a previous commit.
6) Set the Project to the LTS version (e.g. Project 7.x).
Now, don’t do this unless the RM has asked for it! You should still propose potential backports on the original PR, that has been landed on the “master” branch. You do this by adding the Project for the LTS version as well (e.g. Project 7.x). The “rules” for back ports have not changed:
1) They should fix real issues/bugs
2) They must not break compatibility
3) If they add a new feature, they would get on the queue for a potentially upcoming minor release (e.g. 7.2.x). The exception being if the new feature (e.g. new configuration) is needed to fix a serious problem (typically a security issue).
Cheers,
— leif
Example:
commit 363405e6cd07419208fb22b8cb36d59051296aae
Author: Leif Hedstrom <***@apache.org>
AuthorDate: Thu Apr 20 12:50:53 2017 -0600
Commit: Leif Hedstrom <***@apache.org>
CommitDate: Wed Feb 28 09:49:56 2018 -0700
Proper support fort he %{URL:<qual>} conditions
This was never properly, or completely, implemented. This makes sure that
the URL conditions works as both conditions and values. Supported qualifiers
are e.g.
cond %{SEND_RESPONSE_HDR_HOOK} [AND]
cond %{CLIENT-URL:SCHEME} =http
set-header X-Url %{CLIENT-URL}
set-header X-Url-Scheme %{CLIENT-URL:SCHEME}
set-header X-Url-Host %{CLIENT-URL:HOST}
set-header X-Url-Port %{CLIENT-URL:PORT}
set-header X-Url-Path %{CLIENT-URL:PATH}
set-header X-Url-Query %{CLIENT-URL:QUERY}
set-header X-Url-Matrix %{CLIENT-URL:MATRIX}
(cherry picked from commit 8fe3dd266d05d21b2e5bec5f6d914e8eac75e2ac)
Conflicts:
doc/admin-guide/plugins/header_rewrite.en.rst
plugins/header_rewrite/conditions.cc
Sometimes, when a backport request from master to an LTS release has merge conflicts, the RM will ask for a new PR that fixes the merge conflicts. It’s important that we all do these the same way, so here’s the outline on how I think we should do these.
0) Make a branch off the LTS release you want to cherry-pick to (e.g. git checkout -b LeifBackport 7.1.x).
1) Run “cherry-pick -x abcd1234”, the -x here is critical.
2) Resolve the merge conflicts, but retain the commit Subject and message body as it was in the original commit.
3) Uncomment the section that specifies which files has merge conflicts. This would include that as part of the commit message, see the example below.
4) Make the PR on Github.
5) If you have permissions, please make an effort to set the same Labels, Assignees etc. Set the reviewer to the RM for the LTS that you are backporting to. Add the Backport label as well, to make it clear that this was a backport of a previous commit.
6) Set the Project to the LTS version (e.g. Project 7.x).
Now, don’t do this unless the RM has asked for it! You should still propose potential backports on the original PR, that has been landed on the “master” branch. You do this by adding the Project for the LTS version as well (e.g. Project 7.x). The “rules” for back ports have not changed:
1) They should fix real issues/bugs
2) They must not break compatibility
3) If they add a new feature, they would get on the queue for a potentially upcoming minor release (e.g. 7.2.x). The exception being if the new feature (e.g. new configuration) is needed to fix a serious problem (typically a security issue).
Cheers,
— leif
Example:
commit 363405e6cd07419208fb22b8cb36d59051296aae
Author: Leif Hedstrom <***@apache.org>
AuthorDate: Thu Apr 20 12:50:53 2017 -0600
Commit: Leif Hedstrom <***@apache.org>
CommitDate: Wed Feb 28 09:49:56 2018 -0700
Proper support fort he %{URL:<qual>} conditions
This was never properly, or completely, implemented. This makes sure that
the URL conditions works as both conditions and values. Supported qualifiers
are e.g.
cond %{SEND_RESPONSE_HDR_HOOK} [AND]
cond %{CLIENT-URL:SCHEME} =http
set-header X-Url %{CLIENT-URL}
set-header X-Url-Scheme %{CLIENT-URL:SCHEME}
set-header X-Url-Host %{CLIENT-URL:HOST}
set-header X-Url-Port %{CLIENT-URL:PORT}
set-header X-Url-Path %{CLIENT-URL:PATH}
set-header X-Url-Query %{CLIENT-URL:QUERY}
set-header X-Url-Matrix %{CLIENT-URL:MATRIX}
(cherry picked from commit 8fe3dd266d05d21b2e5bec5f6d914e8eac75e2ac)
Conflicts:
doc/admin-guide/plugins/header_rewrite.en.rst
plugins/header_rewrite/conditions.cc