Ludovic Courtès <l...@gnu.org> writes: > Hello Guix! > > l...@gnu.org (Ludovic Courtès) skribis: > >> It’s time to plan for the next release! Here’s what we maintainers >> think should be done for the next release, which would hopefully happen >> within less than a month: >> >> 1. ‘core-updates’ merged. We’re almost there! >> >> 2. ‘wip-installer’ retested, and probably merged. >> >> I think the prerequisite for it would be to do some more testing. >> Last time people reported glitches here and there but John has >> done quite a bit of work since then. John: what about doing >> another round of tests? >> >> In the installation image, we should probably make the installer >> optional and mark it as “beta” or something like that. That will >> leave us time to iron out remaining issues, and will avoid having >> people expect a rock-solid Debian-style installer. >> >> As far as review is concerned, we can probably do a quick and >> lightweight review process since that’s quite a big chunk of code >> and we don’t want the branch to block indefinitely. So we can do >> that quick process, and then incrementally improve it if needed. >> I think it’s a reasonable approach given that the installer is >> mostly an independent component. >> >> John, everyone: thoughts? >> >> 3. UEFI support documented and possibly improved. >> >> We can certainly document the UEFI setup and add the /boot/efi >> partition in some of the ‘operating-system’ examples. >> >> The more difficult part is the installation: do we need to make a >> second, UEFI-specific, installation image? When I installed >> GuixSD on UEFI, I booted our installation image as “legacy”, but >> then GRUB would default to a legacy install, not a UEFI install: >> >> https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00799.html >> >> I’m not sure exactly what needs to be done. Thoughts? >> >> 4. Fix low-hanging fruits at <https://bugs.gnu.org/guix>; your help >> welcome! >> >> Please share your thoughts! > > With UEFI (almost) ready, Guile 2.2 in the house, and “make release”, > should we aim for next week (like Wed. 17th)? Can we focus on polishing > the remaining bits and testing? > > If the schedule turns out to be too tight, we could move to the week > after.
I’d like to merge wip-installer, but not start it by default. It would be a shame to see the branch bit-rot. We also need to fix the glibc on hurd (the patch for i686 should not be applied there), but I haven’t been able to reproduce the failure on hydra. https://hydra.gnu.org/build/2036383/nixlog/1/raw What do you think? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
