Leo Famulari transcribed 1.1K bytes: > On Thu, Apr 06, 2017 at 10:34:29AM +0200, Ludovic Courtès wrote: > > This ‘core-updates’ cycle was terribly long, so I suggest to write down > > a schedule and then try hard to stick to it. ;-) > > At the beginning of the cycle, I was confident that we could build and > merge it in 2 or 3 weeks. But, it took about 6 weeks before we could > merge. > > Something we can all do to speed up the process is try `guix package -u` > and `guix system build`, starting at the beginning of the freeze. [0] > > You will find build failures before they show up on Hydra, and find bugs > and regressions before we merge core-updates into master. Our build farm > is relatively slow and unreliable, so it's inefficient to wait for it to > find build failures; it won't find applications bugs at all in many > cases. > > > Last but not least: who wants to be the timekeeper? The position mostly > > consists in firmly reminding people of the schedule. :-) > > I tried to do it this time around, but we kept finding bugs and > experiencing build failures that we couldn't ignore. > > [0] I was able to rely on core-updates after ~3 weeks (excluding > libreoffice). >
Recently I've started studying other communities and how they function, among them Rust. I wonder how much of what Guix does can be further automated. So that it maybe doesn't take 6 weeks or more for certain features to be merged (building the binary substitutes is another issue of time and resources).
