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?
Is there also a policy that explains when boards are removed? Or what to do to prevent boards from being removed?
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.
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?
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?
Denis.
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
On Tue, 3 Jan 2023 18:38:02 +0100 (CET) Martin Roth gaumless@tutanota.com wrote:
Hi Denis, - Responses inline
Hi,
Thanks for the answers.
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.
[...]
Because the maintainers may not notice the patches, it's always suggested to reach out to the maintainers directly for reviews.
As I understand that file tells only about patch review delays and not what kind of patches are acceptable or not or who is supposed to do the work of converting a board to the newer APIs. I'm mostly interested in two last aspects.
For instance as a Linux contributor, I can send a patch to add a computer (like a smartphone for instance) or contribute fixes and new support to existing drivers, and usually the code gets maintained somehow automatically: - New patches are required not to break existing code, so they have to take care to either keep the compatibility with the old code or update it along the way.
Though older code doesn't necessarily benefit from new features (for instance, for ARM, if nobody converts old C board code to the devicetree, it will still works if people compile support for that ARM computer, but the resulting kernel will only be able to boot on that computer).
The code quality requirements is usually very high in order to reduce the amount of time required to maintain the code.
- If I'd contribute a driver instead, I may end up being its maintainer somehow, so I'd have to review patches. Who will maintain the driver might also be part of the discussion when upstream will decide or not to accept the patch for the new driver.
- Users can test the code and report bugs. If the bugs are reported during patch review, the burden to fix the bug is on the person who sent the patch.
Since there are different policies in Coreboot, I'm trying to understand if it's possible to somehow find ways to get the same kind of assurances than with Linux so that specific mainboards will not be removed, and if so how to do it, how much resources it requires, etc.
If I look at Linux, in the worst case scenario I can look at the number of maintainers for a given driver and expect that the maintainers will at worse, work full time on reviewing patches, so that can be roughly calculated.
There is also information on how to setup automatic test infrastructure (for instance with LAVA) so the resources needed for that can also be predicted somehow.
Here this interest me because I'm trying to evaluate if it makes sense for me and other interested people to contribute big changes to Coreboot, for instance by adding back a mainboard like the Asus KGPE-D16. If we do a lot of work and that this work is removed right after, it's not worth it, so it's best to check beforehand than to have some drama if the huge work is removed.
The issue with Coreboot is that I'm unsure if I can do the same kind of calculation than with Linux: The APU1 was removed despite the fact that the mainboard was "supported".
So this is why I'm trying to understand how much work it is to convert boards and for that understanding how deprecation are decided could give me hints of the amount of work to expect in the worst case.
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.
Here I am wondering precisely how the deprecation of module X is decided. For instance can anyone convert some code in Rust and expect everybody else to learn Rust and rewrite everything in Rust?
Is it up to maintainers of each module to decide when to deprecate module X in favor of module X+1?
If so what are usually the factors taken into account? I assume that if there is too much change to do (like completely rewriting Coreboot in Rust), I assume that they won't be able to force a change like that on the rest of the Coreboot contributors. If that's the case it gives some indication of the amount of work required to convert to newer modules.
It also brings the question of what is taken into account when deciding to deprecate module X. For instance is the maintainability of each "modules" the only concern, or are the amount of supported mainboards and end users a concern too?
Is the amount of work needed to convert from module X to module X+1 taken into account? And is there usually some documentation that explains how to do the conversion? Or are do people need to find out by looking at the release notes and other boards being converted?
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.
That is good: at least we have a way to find that out.
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.`
I'm not sure I'm the right person to do that, and if so how I could do it. I could probably propose a patch to the documentation though, if it's the right place to do it.
For the code, it's probably best if it's done in the commit that deprecates something. For instance for CONFIG_LEGACY_SMP_INIT, we could add the following to the Makefile in the top directory:
ifneq ($(CONFIG_LEGACY_SMP_INIT),) @echo "+----------------------- /!\ WARNING /!\ ---------------------+" @echo "| CONFIG_LEGACY_SMP_INIT is deprecated. |" @echo "| It will be removed in Coreboot release 4.18 (November 2022).|" @echo "| Please migrate your mainboard to CONFIG_PARALLEL_MP, |" @echo "| or it will be removed right after the Coreboot 4.18 release.|" @echo "| See the Coreboot release notes[1] for more details. |" @echo "| [1]Documentation/releases/coreboot-4.16-relnotes.md |" @echo "+-------------------------------------------------------------+" endif
If we add that at the end of the Makefile, to have it show up at the end of the build. We could also add a deprecation target if needed. This way if we do that and that we use a similar format for all deprecations, people building Coreboot will most likely see it.
This way users will not have to read all the release notes at each releases to catch that kind of issues, and if distributions start packaging coreboot or other projects based on Coreboot, then they would see that too.
Denis.
Hello All,
We regret to announce that PC Engines, a provider of small and low-power servers for network security, wireless networking, and embedded applications, has discontinued its sponsorship for open-source firmware. Although this is a significant change for the open-source firmware community, our commitment to supporting the hardware remains strong. At Dasharo, we aim to continue the legacy of PC Engines by distributing open-source firmware and putting the community's needs first. Our focus will be on releases and feature sets driven by community support. We are considering a subscription model to ensure stable and reliable firmware updates. Your input is important to us, and we would appreciate your feedback through our survey at https://forms.gle/MHrT2f1du1Afvwvj9. Please help us understand how we can better serve the open-source firmware community and ensure its success in the future.
Full details: https://docs.dasharo.com/variants/pc_engines/post-eol-fw-announcement
Best regards, Norbert Kamiński Junior Marketing Specialist at 3mdeb
On 4.01.2023 01:17, Denis 'GNUtoo' Carikli wrote:
On Tue, 3 Jan 2023 18:38:02 +0100 (CET) Martin Roth <gaumless(a)tutanota.com> wrote:
Hi Denis, - Responses inline
Hi,
Thanks for the answers.
Jan 2, 2023, 17:16 by GNUtoo(a)cyberdimension.org:
Hi,
The MAINTAINERS file has the following:
PC ENGINES ALL MAINBOARDS M: Piotr Król <piotr.krol(a)3mdeb.com> M: Michał Żygowski <michal.zygowski(a)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.
[...]
Because the maintainers may not notice the patches, it's always suggested to reach out to the maintainers directly for reviews.
As I understand that file tells only about patch review delays and not what kind of patches are acceptable or not or who is supposed to do the work of converting a board to the newer APIs. I'm mostly interested in two last aspects.
For instance as a Linux contributor, I can send a patch to add a computer (like a smartphone for instance) or contribute fixes and new support to existing drivers, and usually the code gets maintained somehow automatically:
New patches are required not to break existing code, so they have to take care to either keep the compatibility with the old code or update it along the way.
Though older code doesn't necessarily benefit from new features (for instance, for ARM, if nobody converts old C board code to the devicetree, it will still works if people compile support for that ARM computer, but the resulting kernel will only be able to boot on that computer).
The code quality requirements is usually very high in order to reduce the amount of time required to maintain the code.
If I'd contribute a driver instead, I may end up being its maintainer somehow, so I'd have to review patches. Who will maintain the driver might also be part of the discussion when upstream will decide or not to accept the patch for the new driver.
Users can test the code and report bugs. If the bugs are reported during patch review, the burden to fix the bug is on the person who sent the patch.
Since there are different policies in Coreboot, I'm trying to understand if it's possible to somehow find ways to get the same kind of assurances than with Linux so that specific mainboards will not be removed, and if so how to do it, how much resources it requires, etc.
If I look at Linux, in the worst case scenario I can look at the number of maintainers for a given driver and expect that the maintainers will at worse, work full time on reviewing patches, so that can be roughly calculated.
There is also information on how to setup automatic test infrastructure (for instance with LAVA) so the resources needed for that can also be predicted somehow.
Here this interest me because I'm trying to evaluate if it makes sense for me and other interested people to contribute big changes to Coreboot, for instance by adding back a mainboard like the Asus KGPE-D16. If we do a lot of work and that this work is removed right after, it's not worth it, so it's best to check beforehand than to have some drama if the huge work is removed.
The issue with Coreboot is that I'm unsure if I can do the same kind of calculation than with Linux: The APU1 was removed despite the fact that the mainboard was "supported".
So this is why I'm trying to understand how much work it is to convert boards and for that understanding how deprecation are decided could give me hints of the amount of work to expect in the worst case.
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.
Here I am wondering precisely how the deprecation of module X is decided. For instance can anyone convert some code in Rust and expect everybody else to learn Rust and rewrite everything in Rust?
Is it up to maintainers of each module to decide when to deprecate module X in favor of module X+1?
If so what are usually the factors taken into account? I assume that if there is too much change to do (like completely rewriting Coreboot in Rust), I assume that they won't be able to force a change like that on the rest of the Coreboot contributors. If that's the case it gives some indication of the amount of work required to convert to newer modules.
It also brings the question of what is taken into account when deciding to deprecate module X. For instance is the maintainability of each "modules" the only concern, or are the amount of supported mainboards and end users a concern too?
Is the amount of work needed to convert from module X to module X+1 taken into account? And is there usually some documentation that explains how to do the conversion? Or are do people need to find out by looking at the release notes and other boards being converted?
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.
That is good: at least we have a way to find that out.
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.`
I'm not sure I'm the right person to do that, and if so how I could do it. I could probably propose a patch to the documentation though, if it's the right place to do it.
For the code, it's probably best if it's done in the commit that deprecates something. For instance for CONFIG_LEGACY_SMP_INIT, we could add the following to the Makefile in the top directory:
ifneq ($(CONFIG_LEGACY_SMP_INIT),) @echo "+----------------------- /!\ WARNING /!\ ---------------------+" @echo "| CONFIG_LEGACY_SMP_INIT is deprecated. |" @echo "| It will be removed in Coreboot release 4.18 (November 2022).|" @echo "| Please migrate your mainboard to CONFIG_PARALLEL_MP, |" @echo "| or it will be removed right after the Coreboot 4.18 release.|" @echo "| See the Coreboot release notes[1] for more details. |" @echo "| [1]Documentation/releases/coreboot-4.16-relnotes.md |" @echo "+-------------------------------------------------------------+" endif
If we add that at the end of the Makefile, to have it show up at the end of the build. We could also add a deprecation target if needed. This way if we do that and that we use a similar format for all deprecations, people building Coreboot will most likely see it.
This way users will not have to read all the release notes at each releases to catch that kind of issues, and if distributions start packaging coreboot or other projects based on Coreboot, then they would see that too.
Denis.
-
Denis 'GNUtoo' Carikli -
Martin Roth -
Norbert Kamiński