Responses in-line. On 6/2/25 12:59, ron minnich wrote: > I think there's been lots of good work done, and I did find the 9front FQA > quite usable. > > What I've had complaints about, and where I think the foundation can help, is > to provide a central place to connect all these disparate efforts; provide > "user journeys" (yes, I'm not fond of the term either) showing how people get > going with Plan 9; and, the most interesting to me, providing a CI facility > for installation to make sure instructions work.
Sure I'd love this. I was under the impression that the topic of referencing 9front on p9f.org was still not concluded however. If someone gives me a box and the ability to spawn more I can have this done in an afternoon. We're already 80% of the way there. I have to ask though, what reports are you getting about installations failing? I don't recall us having installer issues in a very long time. I only had to touch my expect script once when we added the ability to use esp as your 9fat after writing it the first time. If anything we see it more often that someone's specific hardware fails to boot after an install (looking at you HP), then we do see the installer crapping out. I agree with you that this would be very nice to have, but I am not convinced this has been an issue. Or if it has that information has not reached us. Where are these folks who have issues with bugs in the installer? Why can't we have their bug reports? > > For the last 30 years, CI for Plan 9 has been "the most recent person to try > it." This is not a good way to provide a reliable experience. This is not the case any longer, as I pointed out we have nightly builds and test release images ourselves. > When I worked in ChromeOS, we had a large room full of thousands (no > exaggeration) of chromebooks, continuously running installs, all the way up > to login (robots can run trackpads and keyboards; cameras verify screen > images). Every checkin eventually ends up in a test boot. This is a very > common test strategy. I would love this, right now we don't have the funds to do this on our own. This is the common theme between a lot of our shortcomings in the testing department. > > We're not going to go that far, of course. But I think it could be possible > to have a CI for (e.g.) the 9front qemu install, up to and including a > "headless drawterm" that connects via 17010 and verifies that drawterm would > work. The CI could include a compile step for drawterm, as people keep having > issues building it. If devdraw is needed, there should be a build of that too. I haven't put much more effort in to this, but I have this capability with the 9front-in-a-box repo, I've tested it out on github actions already: https://github.com/majiru/9front-in-a-box/blob/front/.github/workflows/run.yml Granted this isn't doing it with a gui, it uses -G. Doing it with a GUI involves a whole different set of challenges but it might be interesting. Maybe tonight I can make this run with the output of the nightly builder, and then we would have what you're looking for. > > It needs to be easier, for people coming from the unix world. Nothing in > their experience prepares them for Plan 9, and no matter how good they are at > this stuff, people find it difficult. It needs to be reliable and easy and, > sadly, it can't require lots of reading. > UNIX itself also has its own challenges if you're coming from the windows/mac world, yet something compels people to learn anyway. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbe8e5fda6ae62f5c-M4d9f923323cce56098e00fe4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
