btw, if you are interested in looking at new abstractions intended to resolve some of the issues we are discussing here, that's what oreboot is all about.
We did just drop the fsp platforms, because we decided there is no interest in binary blobs for oreboot, but other than that ... if you like the idea of full source, Rust, an effort to work out new abstractions, and to remove some legacy coreboot ideas that did not work out ... we're there every friday, with lots of RISCV focus nowadays. I am taking this discussion to heart, and I think in oreboot we're going to try to find a way to record mainboards we've dropped, with their commit, so memory is not lost. Maybe with tags, maybe with plain text file, not sure. It's possible whatever we try out will work for coreboot, but we'll see. On Sat, Apr 16, 2022 at 8:25 AM ron minnich <rminn...@gmail.com> wrote: > > nico, it was not so much a matter of me jumping on the bandwagon, as > my reluctance to get involved in another never-ending discussion over > retiring a platform that nobody uses or cares about. > > But let's keep it simple. I think it's clear that the effort to > maintain the Quark is > 0. The number of users is zero. The effort per > user, depending on what you get when you divide a number by zero, is > "high" :-) > > But there's a bigger issue here. If I have a board, which ran coreboot > at some time, which version of coreboot do I use? In many cases, the > working version of coreboot will not be master. That is true for > chromebooks in many cases, which is why Google maintains a fork for > each chromebook, once it is known to work. If you've been doing this > for long enough, you've experienced building a mainboard at tip of > tree and having it not work; then finding an older commit for which > the board does work. > > This discussion has led me to believe that we should change how we > name branches. People get upset that boards are not in master. Should > we get rid of the entire idea of a master branch which works for all > boards, since that is not quite true anyway? Or is the problem that > people don't want to see a name lost to memory (I understand that)? > Can we maintain a record of boards, along with the last working > commit? > > In other words, builds != boots. But we continue to act as though > boards that build will also boot. This is known not to be true. > > The issue is not whether my board is in master. The issue is, what's > the last known commit in coreboot for which a board was tested and > known to work? > > So we would no longer deprecate boards, or drop them, or do whatever > gets people upset. We would have a way to know, for any given board, > which commit to check out to build it. The list of boards would grow > over time, and it would be easy to checkout a board and build it. > Boards would not be lost to memory. > > We could acknowledge this reality by naming master to tip, or some > similar name, which is less likely to get people upset. > > This was my original goal for the mainboards status page, but we never > got there. Maybe it's time to bring that to life. > > On Sat, Apr 16, 2022 at 7:33 AM Nico Huber <nic...@gmx.de> wrote: > > > > Hi Sheng, > > > > On 16.04.22 11:01, Sheng Lean Tan wrote: > > > Personally I think moving Galileo soc to stable branch is a win-win > > > situation for all of us. > > > > it looks like nobody is maintaining such a stable branch yet. Would you > > volunteer to maintain one for Quark? AIUI, some people already want to > > take care of testing. So you'd only have to maintain compatibility with > > newer toolchain and payload versions and such. > > > > > For the enthusiast who still want to use it are freely to do so without > > > the baggage, and for others it’s a great savings on resources spent, so > > > that we could leave more rooms (and also testing resources)to the more > > > upcoming coreboot products and architecture (I think much more will come, > > > the public has just only warmed up to coreboot ;) ). > > > > FWIW, most resources for newer platforms are wasted by copying code > > (kind of forking the original code in the same repository). So there > > is much more potential to save resources by adding proper abstraction > > instead. And what would be better to get the abstractions right than > > a diverse set of platforms in the tree? I'm not saying, you need Quark > > for that, but so far I also don't see how it could hurt. > > > > Nico > > _______________________________________________ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
