[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Testing the installer
From: |
Mathieu Othacehe |
Subject: |
Re: Testing the installer |
Date: |
Tue, 14 Jan 2020 09:02:26 +0100 |
User-agent: |
mu4e 1.2.0; emacs 26.3 |
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’.
Re: Testing the installer, Jonathan Brielmaier, 2020/01/20