Hi Denis,
- Responses inline
Jan 2, 2023, 17:16 by gnu...@cyberdimension.org:
> Hi,
>
> The MAINTAINERS file has the following:
>
>> PC ENGINES ALL MAINBOARDS
>> M: Piotr Król <piotr.k...@3mdeb.com>
>> M: Michał Żygowski <michal.zygow...@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&area=default
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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
