Hi Mike,
I typically don't indulge in mailing list drama, but I'm sick and tired of seeing people waste their time and energy along with others'. This is not the first time I've seen something like this: something similar happened about two years ago when other AMD boards (KGPE-D16 and KCMA-D8, among others) were slated for removal. It was a difficult decision, but had to be done. I really don't want history to repeat itself again, but I fear it's going to happen unless there's a change of attitude right now.
On Thu, Nov 25, 2021 at 4:05 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:
Note that these boards will only be dropped if no one steps up to adapt their code accordingly. Moreover, the first deprecation notice for RESOURCE_ALLOCATOR_V3 was issued as part of the coreboot 4.13 release notes, i.e. last year. The removal was postponed indefinitely because https://review.coreboot.org/q/topic:amd_resource_allocator_v4 implements the required changes. However, not all patches have landed yet, and efforts seem to have stalled: as of writing, all but one of the unmerged changes were last updated in May 2021, and the outlier was last updated in 2021-06-23. Hopefully, this notice will reactivate efforts to get these patches submitted without reactivating the local mailing list volcanoes.
IMHO, lamenting about deprecation notices on the mailing list is counterproductive: it invests no resources into addressing the root problem (code needs to be maintained, but isn't), but instead tries to somehow avoid having to address the root problem by inciting emotional responses from others, such as anger. In my experience, this is a recipe for a conflict, a bitterly unpleasant waste of many people's time and energy for naught, leading to an equally disgraceful aftermath; a war in which most of the casualties are motives to work on the project. Wouldn't it be much more useful to, say, work on adapting the code, add new features or improve existing functionality, write some documentation, or even check the grammar of the code comments in the tree?
- 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.
In my experience, most people who've contributed didn't have a supported board. I myself got involved with the coreboot community because none of the boards I had was supported; about three and a half years later, I now am one of the most active contributors. I only tolerated the bugs and limitations of coreboot (let's be honest; we're not perfect and we don't provide the same features as vendor firmware) because I was experiencing first-hand how hard firmware development is. I'm pretty sure I wouldn't be writing this email had one of my boards already been supported.
Granted, it's nearly impossible for a newcomer to port a board when its chipset is not supported. The first board I ported is the Asus P8H61-M PRO, an Intel Sandy/Ivy Bridge desktop board with a serial port and a socketed DIP8 flash chip. Back then, Sandy/Ivy Bridge was one of the best-supported platforms (and still is, as of writing). Several people on IRC (to which I'm forever thankful) helped me port this board. I only know of one person on IRC that could help porting an AMD board using AGESA, and there aren't many people who have AGESA-supported boards.
- 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.
First and foremost, there's support for older Intel boards that don't require ME firmware or simply don't have a ME at all, and people still use them. Besides AMD AGESA boards, the other boards that need to be updated are AOpen DXPL Plus-U (a dual-socket server board that uses Netburst Xeons, no other board in the tree uses the same chipset code) and various Asus P2B boards (which support Pentium 2/3 CPUs, these boards are older than me). Even though I only know two people who still have some of these boards (and they don't have the same boards), they're still supported because the code has been maintained so far.
If there are contributors who only have these boards, where are they? Why aren't they trying to adapt the code? If they don't know how, why haven't they asked for help on how to proceed? I understand that most users wouldn't know how to implement the required changes, but they can still test things! If they don't want to test things, they might as well keep using the coreboot image they're currently running.
- 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.
I'm sure the effort required to adapt the affected platforms is less than the effort required to backport changes from coreboot master. As to whether dropping boards may harm the reputation of the coreboot project, it's unclear. Some people will hate it, others will be sad about it, and others will understand that dragging support for platforms no one is maintaining is unnecessary burden. As a developer, I'd rather support less platforms and make them work well than try to support everything at the expense of quality.
Of course, the people may finally fork a coreboot to i.e.
Who does "the people" refer to? The maintainers of these boards? The users? I have no clue, could you please elaborate?
"coreboot_extended" or "coreboot_notcorporate" (need a good name) and
This is an insult to the coreboot community. A significant amount of contributions don't come from corporations. One of the most important contributions to coreboot has been Sandy/Ivy Bridge native raminit, which wasn't done by corporations. In fact, native raminit is reimplementation of the MRC.bin introduced by corporations.
Let's not forget about the origins of AGESA. As far as I'm aware, it came from AMD and hasn't seen much non-corporate development, let alone any efforts to reimplement its functionality. How exactly is AGESA not corporate?
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.
I'm very interested in knowing what your plans are to make such a promising fork thrive. How would a fork require less work than backporting the changes from coreboot master? Unlike continuing development in a branch, a fork would not be able to reuse the existing coreboot infrastructure (e.g. Gerrit, Jenkins...). Would the maintainers of such a fork also maintain the boards supported by upstream coreboot?
But, if this happens, it will fragment the coreboot community and split / spread thin our joint efforts for not a good enough reason.
How exactly does threatening to fork avoid fragmenting the coreboot community? Wouldn't it be much better to focus on the root problem, that platform code needs to be adapted and tested? Or is there a good enough reason that I have completely missed?
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.
Could you please provide concrete pointers to this "active development & maintainership" you're referring to?
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.
So you have the hardware. Would it be OK with you to test patches that implement the required changes? Or even better, would you like to try implementing such changes? Why not both?
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.
Helping out 10 people at the same time sounds stressful. Would writing some documentation for https://doc.coreboot.org/ on how to get coreboot running on these boards reduce the amount of work you need to do?
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.
So, if you agree that making them work with resource allocator v4, why not work on getting https://review.coreboot.org/q/topic:amd_resource_allocator_v4 submitted? It doesn't look like a lot of effort. I'll be happy to help review these changes: my reviews are remarkably rigorous, but I'm not a draconian warden of the submit button.
-- 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
TL;DR: The deprecation notice is a call for action. Please stop complaining about it, let's work on a solution instead. Especially when https://review.coreboot.org/q/topic:amd_resource_allocator_v4 already exists, which implements some of the required changes.
Best regards, Angel