[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘core-updates’ schedule
From: |
Ludovic Courtès |
Subject: |
Re: ‘core-updates’ schedule |
Date: |
Fri, 07 Apr 2017 17:22:13 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Heya!
Leo Famulari <address@hidden> skribis:
> 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.
True (I did that but could have done it earlier.)
>> 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).
Yeah, that’s right. I’m not saying it would have been easy to avoid the
delay; it’s obviously very tricky to get right, and gets more difficult
as the package collection grows. Clearly you and Marius did a great job
at fixing bugs and making sure we’d make progress!
My thought was that fixing specific dates might help get everyone
psychologically prepared and ready to focus on stabilizing the branch
when the time comes.
Ludo’.