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:
1. 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.
2. 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.
3. 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/