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 <zw...@apache.org>
AuthorDate: Thu Apr 20 12:50:53 2017 -0600
Commit:     Leif Hedstrom <zw...@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


Reply via email to