Defect #20456
Updated by Mischa The Evil over 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.