[M] Change in coreboot[main]: mb: source site-local mainboard Kconfig.name and Kconfig files

[Felix Singer (Code Review)]

Attention is currently required from: Alexander Couzens, David Hendricks, Evgeny Zinoviev, Felix Held, Jeremy Soller, Jonathon Hall, Martin L Roth, Michael Niewöhner, Michał Żygowski, Philipp Hug, Piotr Król, Ron Minnich, Sean Rhodes, Tim Crawford.

Felix Singer has posted comments on this change by Martin L Roth. ( https://review.coreboot.org/c/coreboot/+/83119?usp=email )

Change subject: mb: source site-local mainboard Kconfig.name and Kconfig files
......................................................................

Patch Set 2: Code-Review-1

(1 comment)

Patchset:

PS2:
> I don't think we allow symlinks to be checked into the coreboot repo, though I do see some in submod […]

I wasn't saying that symlinks should be checked in the coreboot repo, but this is what the symlink target from the Makefile does, as far as I can tell. I don't know how it works, but I assume this is only done locally when the user intends to use site-local. So, that's why I've asked why that doesn't work anymore.

Are any more changes expected or even planned in order to integrate downstream code into what's available on the main branch? I feel this is heavily working around git branches, which also should work on Windows.

I understand that people from here intend to upstream their changes at some point, but I feel this might encourage others to not upstream changes since it becomes more comfortable to work downstream. Well, here it's "just"(?) mainboards from site-local which are integrated into the upstream infrastructure. I dislike the fact that upstream should provide infrastructure for whatever is done downstream somewhere. git branches seem more appropriate to me. That's why I give a -1 to this.

As an alternative to this, but not sure if this makes it better or worse or no change at all, I'm thinking of a dedicated site-local mainboard vendor directory, which hooks up mainboards from site-local. It still does the same thing as what is proposed here, but then it's limited to that directory and not applied to the general infrastructure, which might be less encouraging to keep changes downstream.