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
