Defect #20456
Updated by Mischa The Evil almost 9 years ago
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 ;-)...
<pre>
------------------------------
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
</pre>
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 #1834-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.