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

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.

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

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:

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