Am 25.11.2021 um 18:06 schrieb AreYouLoco? via coreboot:
In my opinion coreboot is more developer friendly than user friendly.
Kinda obvious: We don't even ship binaries...
Given the trouble these deprecation announcements always are, I can tell you an even more developer friendly strategy:
We could simply make all boards compile _somehow_ with the new infrastructure and retire the old one because it fell out of use. Without telling anybody.
If such a change lands in, say 4.16, and you only think of updating your firmware in, say 4.20, there has been one year of development going on after the removal (assuming the newly-proposed quarterly release schedule).
The result: fixing the issue becomes much harder, by then, rolling back is impossible, and nobody can quite remember what the issue was.
That strategy is more developer friendly because we don't have to deal with crap on the mailing list. Is it more user friendly?
And board depreciation is not a good idea. I understand that they can be brought back at some point. But lets be realistic that this need some developer time and testing. And in capitalistic world that means money to support old boards.
It also costs developer time to keep maintaining several alternate code paths, some of which are only used for boards no developer still uses (or they would have patched them to use the new code already).
As it stands, the proposed timeline allows for:
- ~2 more months to intervene before that list of boards even makes it into some official release notes. Adapt a board to the new infrastructure before then and it can disappear from that list before it even becomes official.
- 6 additional months in which the announcement is out in the open but the code is still in ToT. Adapt a board to the new infrastructure before then and while the old infrastructure will be dropped, the board won't be affected.
Even after that, all the existing coreboot versions are still there.
There are already some patches out there, so it appears that the strategy how to adapt a board to the new infrastructure is well understood - we're lacking the ability to test these boards.
Even if you can't adapt a board yourself, I'd suspect that announcing that you have some piece of hardware, can provide logs and offer to run tests will spark interest in developers creating a patch for the board.
We just don't do that speculatively because while it's usually simple to make a board compile it's far from clear that the result will still boot.
So: what board(s) are you offering to test?
Patrick