Hello Ludo,
That sounds like a nice idea! I guess we can discuss it more deeply during Guix Days, but here are a few thoughts: * Testing from a VM won't cover HW issues with undetected wifi networks and kmscon rendering issues, but could cover most partitioning issues. * This kind of client/server protocol would make even easier to switch to a gtk graphical installer. * Before the next release, it would be nice to fix the "installer always fail when restarted" issue than has been bitten lots of people. Thanks, Mathieu Ludovic Courtès writes: > Hello Guix! > > One of the lessons from the 1.0.0 screw-up was that we should test the > graphical installer itself: > > https://guix.gnu.org/blog/2019/gnu-guix-1.0.1-released/ > > I think we should try to do that before the next release; not doing it > means testing by hand, which also takes a lot of time. > > One idea that I had was that we could change the installer so that it > listens for connections on some pre-defined Unix-domain socket. When it > gets a connection, it would perform a dialog with its client: sent it a > summary of the current form, wait for its choice, and so on. The forms > would thus be unavailable from the keyboard: essentially ‘run-form’ > calls would be replaced by ‘draw-form’ calls in that mode. > > Our test infrastructure would thus connect (from a marionette) to the > installer and participate in that dialog. It could even take a QEMU > screenshot at each step. > > How does that sound? Am I overlooking things? > > I guess the difficulty will be to represent questions and answers. > > Ludo’.
