> I do not consider marketing or pure "I do not like this name" as valid > reasons, because this is developer string (or kernel/distro > configurator) not end-user visible thing. And for us, the developers, > this marketing does not matter.
I'm not sure I'd agree that naming doesn't matter for developers? The style guide has an entire section about choosing good names for C symbols, I don't think Kconfig symbols are fundamentally different in that regard; they're still strings developers read to find and make sense of things, and leaving something with the wrong name makes it harder for the reading developer to find and understand it. (This isn't about "marketing", btw, Google the company doesn't care whether this driver is called GOOGLE or COREBOOT. I care as a kernel developer that this driver has been mostly used for something else than what it was originally labeled for for a long while and it's high time that we correct that to avoid confusing people.) > Anyway, defconfig change must be separate because it goes via different > tree, unless this is non bisectable. Keeping it here initially confused > me into thinking you are actually breaking use cases (which you are not). Fair enough. So Sean, could you maybe split this out into this patch which does everything (the renaming and adding of transitional symbols) except for the arm64 defconfig change, and then the defconfig change as a separate patch at the end of the series so that it can go through a different tree?
