Hi Denis, - Responses inline
Jan 2, 2023, 17:16 by GNUtoo@cyberdimension.org:
Hi,
The MAINTAINERS file has the following:
PC ENGINES ALL MAINBOARDS M: Piotr Król piotr.krol@3mdeb.com M: Michał Żygowski michal.zygowski@3mdeb.com S: Supported F: src/mainboard/pcengines/
But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: Remove AMD family14 boards") actually removed the apu1 (src/mainboard/pcengines/).
Is there some policy somewhere that describes what kind of support to expect from maintained boards?
Yes, It's in the maintainers file itself:
Supported: Someone is continuously paid to look after this and a reaction to review requests can be expected within a few days, a month at most. Maintained: Someone actually looks after it and a reaction to review requests can usually be expected within a few weeks. Odd Fixes: It has a maintainer but they don't have time to do much other than throw the odd patch in. See below.. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that.
Because the maintainers may not notice the patches, it's always suggested to reach out to the maintainers directly for reviews.
Is there also a policy that explains when boards are removed? Or what to do to prevent boards from being removed?
We do have that policy, though it could probably be written a bit more plainly.
Here's the search in the coreboot documentation. https://doc.coreboot.org/search.html?q=deprecation&check_keywords=yes&am...
Here's the template for the release notes:
Deprecation notices are part of release notes to act as a warning: at somepoint in the future some part of coreboot gets removed. That point must beat least 6 months after the release of the notice and it must be right aftersome release: That is, the specified release must still contain the part inquestion while one git commit later it might be removed.
The usual reason is progress: Infrastructure module X has been replaced byinfrastructure module X+1. Removing X helps keep the sources manageableand likely opens opportunities to improve the codebase even more.Sometimes everything using some module has been converted to its successoralready and it’s natural for such modules to be removed. Even then it mightbe useful to add an entry to the release notes to make everybody aware ofsuch a change, for maintainers of incomplete boards that they might keep intheir local trees and also to give credit to the developers of that change.
For instance u-boot warns when building that a boards needs to be adjusted to the newer driver model. So just by building u-boot you know in advance what needs to be fixed and for when.
I've looked in the Coreboot documentation but I didn't find any information about that.
Someone could definitely add something to put up a notice when doing the build, but that doesn't exist right now. If it's not something that you're interested in doing, you could file a bug if you think it should be added.
Also is there some public information on how much work it is to avoid a board being removed? Does it require to dedicate someone full time on it? Or does it usually requires less time?
It depends on the item. I don't know what "usually" might be in this case.
Also how changes that break other people's code are decided? Can anyone submit these changes and get them accepted with very few people agreeing to them? Or is there another procedure for these special changes?
People are not allowed to knowingly submit changes that break other platforms. If they do submit a change that breaks things, it can either be reverted, or people can work together to fix the issue. This of course depends on the issue and its severity.
I hope this helps answer your questions.
Martin