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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
