Hello Guix! I think it’s time to think about what we want to work on next, ideally before the next release, and ideally said release should be in a couple of months rather than in 5 months. Here are some important items I can think of: • Merge the ncurses installer (the ‘wip-installer’) branch. • We’re supposed to freeze ‘core-updates’ in a couple of days and we have defined a couple of important goals: . I have a vague feeling that the ‘wip-build-systems-gexp’ merge is not for this time yet… • ‘guix offload’ terrible bug: . • Guile 2.2 compiler terrible issue: . • Adjust the release process so we don’t find ourselves without substitutes for the ‘guix’ package, as reported at . • Prepare to migrate to the new build farm: the hardware of bayfront.guixsd.org has been fixed (it was unreliable until we changed its CPUs), so now we need to fix a couple of issues in Cuirass and generally improve it so we can, via its HTTP interface, add new jobsets and so on. Of course we’ll have to work on that incrementally. • Finalize the new bootloader API and support for new bootloaders: . • Merge the potluck! I think everything above could pretty much go into a 0.13.1 release not far away. And the missing bits, IMO, for a “1.0” label would be: • Improve the UI: add colors (yay!), hide build logs by default for most commands, improve progress reports, display how much will be downloaded, etc. • Implement channels: . A first step may be to fix some of the obvious shortcomings of ‘guix pull’: use (guix git) to optimize bandwidth usage, and compute the derivation of the new ‘guix’ and use that. • Authenticate Git checkouts: . What do people think? I think the key idea is that we should fix all the annoyances and bugs, many of which seasoned Guix hackers more or less got used to, but which are nevertheless a serious hindrance when using Guix “normally.” Ludo’.