[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What’s next?
From: |
Ludovic Courtès |
Subject: |
What’s next? |
Date: |
Wed, 24 May 2017 15:11:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
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:
<https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00120.html>.
I have a vague feeling that the ‘wip-build-systems-gexp’ merge is
not for this time yet…
• ‘guix offload’ terrible bug: <https://bugs.gnu.org/26976>.
• Guile 2.2 compiler terrible issue:
<https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html>.
• Adjust the release process so we don’t find ourselves without
substitutes for the ‘guix’ package, as reported at
<https://bugs.gnu.org/27032>.
• 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:
<https://bugs.gnu.org/26339>.
• Merge the potluck! <https://bugs.gnu.org/26645>
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: <https://bugs.gnu.org/22629>. 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: <https://bugs.gnu.org/22883>.
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’.
signature.asc
Description: PGP signature
- What’s next?,
Ludovic Courtès <=
Re: What’s next?, Brendan Tildesley, 2017/05/24