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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
