Redmine

This was reported initially by Ryosuke Hirai in #11253-38:

it seems that issue_query.rb @ Revistion 14406 was not applied to the source code of 3.1.0. I could not find this part after downloading.

After I read that I started another round of commit hunting. I have summed up the issues I found – and how I found them, using some ASCII-"art". See below.
I'll start with a to-do section which list the commits that needs to be merged in 3.1-stable, the commits that can/should be merged in 3.1-stable and the commits that shouldn't be merged into 3.1-stable since they are related to issues that are explicitly targeted to 3.2.0 at the time of writing this.
Then I start a section which compares the commits on trunk versus the commits (backports/merges) on 3.1-stable which in the end provides a list of commits applied on trunk but not on 3.1-stable, which I in turn used to specify which commits belong to what and what should be done them. That itself is what I used to fill in the to-do section.
Note that I also include a third 'legend' section to make sure that my "art" can be understood ;-)...

------------------------------
1. To do on 3.1-stable branch:
------------------------------

  * To merge...........: r14405, r14406, r14407, r14408, r14409, r14410, r14454
  * Merge-able.........: r14390, r14391, r14411, r14412, r14413, r14414, r14415, r14416
  * Shouldn't be merged: r14458, r14468, r14469, r14470, r14471

------------------------------
2. Commits scheme & reasoning:
------------------------------

v -> TRUNK
|
|
|
O -> r14378
|\
| \
v  --------->--------- O -> r14379, 3.1 STABLE BRANCH CREATION
v                       \
|                        ---->v
|                             |
8 ->   X14380, X14381, X14388,| X14389, r14390, r14391, X14392, X14394,
       X14396, r14405, r14406,| r14407, r14408, r14409, r14410, r14411,
       r14412, r14413, r14414,| r14415, r14416, X14417, X14428, X14429,
  --<< X14430, X14437, X14440,| X14443, X14446, X14448, X14450, X14451,
 /     r14454, X14455, X14419,| X14420, r14458, X14459, X14460, X14461,
/      r14468, r14469, r14470,| r14471                                  <<------<-
|                             |                                                  |\   
v                             v                                                  ^ ->  ((r => X) == (MARKED AS CONFIRMED AS MERGED
|                             |                                                  |/                  FROM TRUNK TO 3.1-STABLE))
|     --------------------->> | >>---------------------------------------------->-
|     |                       |
|     |                       8   -> r14382, r14385, r14393, r14395, r14397, r14400, r14403,
|     ^                              r14418, r14421, r14422, r14431, r14432, r14433, r14438,
|     ^                              r14441, r14444, r14447, r14449, r14452, r14453, r14456,
|     |                              r14462, r14463, r14464,                                  >>----
v     |                                                                                            |
v     ----------------------<<   Merged r14461, Merged r14460, Merged r14459, Merged r14455,       |  
|                                Merged r14450, Merged r14451, Merged r14448, Merged r14446,       O -> MERGE COMMITS, FROM TRUNK
|                                Merged r14443, Merged r14440, Merged r14437, Merged r14430,       O    TO 3.1-STABLE
|                                Merged r14429, Merged r14428, Merged r14420, Merged r14419,       |
|                                Merged r14417, Merged r14388, Merged r14389, Merged r14396,       |
|                                Merged r14394, Merged r14392, Merged r14380, Merged r14381,  <<----
|
|
v
v -> WRAPUP & CONCLUSION: COMMITS ON TRUNK AFTER 3.1-STABLE BRANCH CREATION, THAT ARE NOT MERGED INTO 3.1-STABLE
v
|
8 --> r14390, r14391,                                  --->>> NOT EXPLICIT 3.1.0, BUT IT WAS PROBABLY INTENDED FOR 3.1.X THOUGH
|
8 --> r14405, r14406, r14407, r14408, r14409, r14410,  --->>> EXPLICIT 3.1.0, #11253 AND RELATED
|
8 --> r14411, r14412, r14413, r14414,                  --->>> UNKNOWN, CAN BE BACK-PORTED TO 3.1: "CODE (LAYOUT) CLEANUP & HTTP => HTTPS" 
|
8 --> r14415, r14416,                                  --->>> UNKNOWN, MIGHT BE BACK-PORTABLE TO 3.1: "TRAVIS CHANGES, #20251" 
|
8 --> r14454,                                          --->>> EXPLICIT 3.1.0, "BG LOCALE REORDER", #11253 AND RELATED
|
8 --> r14458, r14468, r14469, r14470, r14471           --->>> EXPLICIT 3.2.0

----------
3. Legend:
----------

  *  -, >, >>, <, <<, ^, v: DIRECTION MARKERS
  *                      O: BRANCHPOINT, COMMIT
  *                      8: MULTIPLE COMMITS
  *                    -->: MULTIPLE COMMITS SPECIFICATION
  *                     ->: COMMENT
  *                     =>: == REPLACED BY
  *                 --->>>: CONCLUSION INDICATOR

I'll leave the scheduling decision (strict: 3.2.0, lenient: 3.1.1) to the committers.

Please note that this issue brings me to issue #18134 again, and in particular to the questions I raised in its note #18134-5 (before "The examples:"). If SCM-provided merge tracking features are used and maintained correctly, issues like this one and previous #18174 could have been spotted right on with some higher certainty. Just my two cents...

Kind regards, Mischa.