Ludovic Courtès writes: > 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:
Great points! > • 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. > > 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.” +1 A friend of mine is having a second look at Guix (not SD yet) and one of the most confusing things initially is `guix pull'. "When/how do I use that," he asks...and I can only say: I'm not using that...I think we want this to work--or something like this, we talked about this at FOSDEM, but AFAIK everyone is using Guix with Git. He responds with: then *why* is it in the manual. I have no answer. Possibly I'm wrong and/or my information is outdated? Greetings, janneke -- Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
