Dear Martin,
Thank you very much for taking the time to answer.
Am 19.06.23 um 22:31 schrieb Martin Roth:
Duplicated code between mainboards isn't a big issue in my opinion. It allows the boards to be customized without worrying about other companies' mainboards. We've tried to make mainboards as small as we can, and we can keep refactoring things out where it makes sense.
Are you talking in general or in this specific SRP boards. As stated by others, a lot of code was copy-pasted.
If some common code fits under the SoC, that's great, and I'm all for moving it there, but let's not force the burden of that refactoring work onto inexperienced mainboard maintainers. Doing so just encourages vendors to keep their mainboards in private repositories - the opposite of what we should be working for. Even if this means that it doesn't get refactored and gets a bit out-of-date, I find that preferable to making contributors (more) frustrated about getting their boards accepted.
I haven’t seen any frustration. Do you know more? I agree, nobody should be frustrated. The question has to be answered though, who is going to do that general maintenance work – I think Kyösti raised a similar question a few weeks back. I welcome all new contributors, but it has to be clear, that coreboot – especially for commercial offerings – needs and expects some kind of maintenance commitment. I am pretty sure, the vendors are going to understand the benefits. It just has to be communicated transparently.
CRBs are (as the name says) reference boards and it should be absolutely fine to duplicate their code when another mainboard vendor uses the CRB as their base - that's what the CRB is for - as an example. Forcing the board to be under the intel vendor directory tells me that intel is responsible for the board, when that isn't the case.
Isn’t `MAINTAINERS` the source for the responsibilities?
In my opinion, Mainboards should be free to customize anything and everything in their directories without having to worry about what other mainboards are affected. I think for the most part, variants should be reserved for duplicates that are owned/maintained by the same vendor. Whitelabel vendors like Clevo can be an exception to this, but the chip vendors' CRBs should not be forced as a baseboard for some other company's design.
Well, that is the thing to discuss. What differences are there going to be and can variants be extended or a new model be found to make it easier to maintain the hopefully vast number of new server boards?
Maybe Angel’s suggestion to submit the boards and then refactor is good. The other way would be to try variants first, and if that does not work, split them out. I’d welcome, that there is some commitment for further work on that though, and I try to avoid that the AGESA experience repeats, where coreboot didn’t want to frustrate AMD and trusted AMD’s promises, but, due to whatever reasons, it only resulted in frustration in the project itself.
Kind regards,
Paul