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?
To make it possible for very different hardware in one branch, thoughtful design is needed.> 1. These boards will be gone for the people who check the "mainboardsCoreboot supports a lot more platforms than "new Intel stuff", which is quite an achievement.
> 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.Supporting different codepaths to do the same thing blows up the complexity of maintenance and makes it harder tosupport 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 addinga minor feature like you said in your previous email. It's really about keepingthings manageable long term for everyone. That however requires some workfrom 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.RegardsArthur_______________________________________________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