What’s next?

[ludo@gnu.org (Ludovic Courtès)]

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

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’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]