On Thu, Apr 21 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> I'm happy to rephrase it however you'd like, but I'm a bit confused by >> the "saw any mention in the proposed log message". I'm fairly sure >> paragraph 2 onwards covers this, i.e. how linux-gcc's behavior is >> changed (as it also regressed). > > Yeah, true, """Likewise for the linux-gcc job CC=gcc-8 was changed > to the implicit CC=gcc, which would select GCC 9.4.0 instead of GCC > 8.4.0.""" that you wrote is exactly about it. > > I was confused because immediately after that you said it was not a > bug, so I dismissed it as not part or the real issue. Perhaps > striking that "not a bug" part may make it less confusing? I dunno. I'll rephrase it, but I probably won't get to it tonight, sorry. What I was trying to get at is that the linux-TEST-vars job was affected, and *does* have a CC_PACKAGE defined, but in that case (and I was the one who split it out) the point was never to have it use its own compiler. For any of these platform/compiler combinations it's enough if we cover that platform/compiler verison once. So the right thing to do with linux-TEST-vars is to just have it use "vanilla", because it's special in other ways. So if and when it fails we don't want to worry about untangling the two variables. I.e. is it the special-versioned compiler, or is it (and it almost always would be) the GIT_TEST_* variables. In that case we should only need to worry about the latter. >> What I suppose is left undiscussed is that jobs that don't define >> CC_PACKAGE at all won't be impacted, is that what you wanted to be >> explicitly mentioned? > > Yes, I agree that is a good idea, too. Or you can steal the "before > and after" table I gave you in the message you are responding to, if > you think it helps. *nod*
