When platforms stand in the way of improving the general code base, I think that's it's not controversial

to ask people to either step up and do necessary maintenance or move the platform to a branch. Past examples of

that would things like dropping romcc bootblock, car global, ...

When a platform is pretty much dead, mainly because it's old or unused, but not standing in the way of general

improvements, I don't think there is much to gain from moving it to a branch. For instance with the i440bx platform
which is over 20y old (I do hope no one has to really use those!), we had someone maintain it a few years back.
I think it was done for the fun of it and I think there is value to that. So maybe someone will have fun with quark in a few years,

fix some problems and make it work again, with the upshot of having a new community member?

Old platforms should not drag down development on the master branch. If you need to make a change to soc/quark and

no one is there to test it, then so be it... That does mean that we can't guarantee that things work in the

master branch, which as I see it is already the case to a large extent on a lot of platforms.

Not breaking platforms in the master branch is an orthogonal problem that can only be solved with automated

hardware testing. It is a *hard* and therefore expensive problem to solve...

Now what should we do when something old is suddenly tested to be broken in the master branch? That's a different

problem where moving things out of the master branch might make more sense.

Kind regards

On Wed, Apr 13, 2022 at 2:42 PM Peter Stuge <peter@stuge.se> wrote:

Michael Niewöhner wrote:
> > But once code is moved off master reuse of changes on master will
> > eventually become impossible and there's no good path to recover from
> > that situation, so it should be important to avoid such dead ends for
> > any code we want to stay usable - IMO all code.
>
> How would you "reuse [] changes on master" on a platform, where these
> changes can't be tested? o.O

By reuse I don't mean that code runs, I mean that a commit benefits
also platforms without test coverage.

There are many ways to determine whether a commit benefits a platform
or not, testing is just one way and testing alone is a weak indicator.

That's perhaps foreign to someone with a "test-driven" mindset. I
don't hate on testing at all, I just want to preserve value also
where there's no coverage when that's possible without much detriment
to other parts of the code.

I don't think it's reasonable nor is it current practice to require
every commit to be tested on every affected platform. That would
obviously be nice data points to have but that has not been coreboot
reality in the past 20 years and I predict that it will also not be
so in the next 20 years. I think that's fine.

I hope you can understand that my ask is simply to not erase what
might be working well based only on a lack of information.

I'm obviously grateful that the leadership meeting settled on keeping
quark at least as long as it causes no problems. Thanks for that!

Kind regards

//Peter
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org