It's definitely preferable to have platforms working in-tree rather than out of tree. This is a *significant* portion of coreboot's supported platforms and sends a strong signal to anyone using or considering them that they can just forget about the coreboot project because the rug may be pulled out from under them at any time.
These users didn't contribute fixes to their boards (or even just feedback
that things needs to be done and testing when others provide patches) - are they even contributors? It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist?
People constantly complain about a lack of developer manpower, yet also don't care about how many users coreboot has. Do you not see that the only source of the former is from the latter?
Loco is right about coreboot being more developer focused than user focused. While there is now (finally!) some sane documentation for simple things like creating a patch on gerrit, these few guides are very hard to find especially from the coreboot.org frontpage. I'm still not aware of anything even approaching a comprehensive porting guide. There is effectively no path for users to follow to fix even the simplest bug. (eg. I'd love to port from the AM1I-A to the AM1M-A, owning spares of both, but the lack of guidance makes the process a black hole of inestimable time)
This is in STARK contrast to a project like PostmarketOS which puts a lot of thought into bringing users into development work. They have font-page guides that go into great detail on creating a new port. They even have detailed guides on how to port a phone to the mainline kernel, for absolute beginners. They have a simple all-in-one script that build the environment, can create the files for a new port, and can automatically package these changes for review. There are a lot of lessons to be learned from pmOS who ran into exactly this problem and fixed it.
On Thu, Nov 25, 2021 at 12:17 PM Arthur Heymans arthur@aheymans.xyz wrote:
- These boards will be gone for the people who check the "mainboards
supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
Coreboot supports a lot more platforms than "new Intel stuff", which is quite an achievement. To make it possible for very different hardware in one branch, thoughtful design is needed. Supporting different codepaths to do the same thing blows up the complexity of maintenance and makes it harder to support both old and new boards as you lose track of how code changes can affect other systems. Keeping things simple is not optional in a project like coreboot. So it's not about adding a minor feature like you said in your previous email. It's really about keeping things manageable long term for everyone. That however requires some work from time to time on some platforms and sometimes dropping boards if no one steps up to do that work.
- It's not just the loss of boards - it's also the loss of coreboot
users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place.
Sorry, not buying that argument at all for AMD AGESA supported platforms. I don't see a lot of development on gerrit for these platforms especially in comparison with Intel ones of similar age.
Regards Arthur
On Thu, Nov 25, 2021 at 5:04 PM Mike Banon mikebdp2@gmail.com wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A
board is never really gone.
"Dropping" 50 boards may be ominous in relation to the future of the coreboot project:
- These boards will be gone for the people who check the "mainboards
supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us.
- It's not just the loss of boards - it's also the loss of coreboot
users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place.
- Unless someone will be manually copying all the time, these boards
won't get the updates of the common coreboot parts, even if such updates aren't related to the deletion reason. A reason which won't be understood by the opensource-loving community around the world - on Phoronix etc. - as good enough for "50 boards drop" - so doing this may harm the reputation of a coreboot project.
Of course, the people may finally fork a coreboot to i.e. "coreboot_extended" or "coreboot_notcorporate" (need a good name) and continue contributing there. Such a fork may even become more popular than the original coreboot of the future, because it will support significantly more boards. But, if this happens, it will fragment the coreboot community and split / spread thin our joint efforts for not a good enough reason.
It's just that active development ends, as no one is working to keep
them up to date. There is a cost to keeping boards too long when there is no one maintaining them.
Even right now there's an active development & maintainership (as evidenced by all these changes at review.coreboot.org), - just not for this v4 resource allocator.
Would it be ok with you to drop the board, and bring it back when it is
working again?
I'm not sure I understand: at least my boards from this list are working perfectly at the moment.
They may still build, but they can stop working. People should be able
to count on a board working if they build an image.
I am often build-testing my boards (didn't notice a https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only because I've been re-using the previously built toolchains to save time). Also, I am actively tech-supporting all the people who would like to build coreboot for AMD boards from this list, even right now I am in an active message exchange with >10 people who are switching to these boards to run coreboot on them - and any user may give back to the project one day.
Hopefully my post above explains why I think "dropping 50 boards is a bad idea", although I agree that it would be nice to get a resource allocator v4 working on them.
On Thu, Nov 25, 2021 at 12:46 AM ron minnich rminnich@gmail.com wrote:
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone. It's git. I can still find the Alpha boards in there if I go back far enough. It's just that active development ends, as no one is working to keep them up to date.
Would it be ok with you to drop the board, and bring it back when it is working again?
There is a cost to keeping boards too long when there is no one maintaining them. They may still build, but they can stop working. That's happened and in my view it's best not to let it happen. People should be able to count on a board working if they build an image.
Thanks
ron
On Wed, Nov 24, 2021 at 12:16 PM Mike Banon mikebdp2@gmail.com wrote:
With all due respect, dropping support for the majority of AMD boards
- with a quite significant community around them! - doesn't seem like
a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs...
Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this.
On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans arthur@aheymans.xyz
wrote:
We could announce this deprecation in the 4.16 release notes,
then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
That timeline of 8.5 months does sound fair. I just found this
updated release schedule in the meeting minutes.
If we are going to release every 3 months then I guess that's a
good way to go.
I started a CL: https://review.coreboot.org/c/coreboot/+/59618 .
I'll update it to reflect that schedule if it can be agreed upon.
On Wed, Nov 24, 2021 at 6:07 PM Martin Roth gaumless@tutanota.com
wrote:
Hey Arthur,
Nov 24, 2021, 05:50 by arthur@aheymans.xyz:
> Hi > I would like to suggest to deprecate some legacy codepaths
inside the coreboot tree and therefore make some newer ones mandatory.
> ... snip ...> About the timeline of deprecations. Is
deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal?
> I have no strong opinion about the platform deprecations, although
I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase.
My preference would be to announce deprecations in the release
notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now.
We could announce this deprecation in the 4.16 release notes, then
deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch.
Would this schedule work?
Martin
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org