Hi
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