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 <mikeb...@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?

> 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.

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.

> 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.

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.

> 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.

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-le...@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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Reply via email to