‘core-updates’ schedule

‘core-updates’ schedule

[Ludovic Courtès]

Hello Guix!

This ‘core-updates’ cycle was terribly long, so I suggest to write down
a schedule and then try hard to stick to it.  ;-)

What about this:

  • May 25th, ‘core-updates’ branch frozen (i.e., rebuild-the-world
    changes are no longer accepted);

  • June 15th, ‘core-updates’ merged in ‘master’ (i.e., most regressions
    compared to ‘master’ have been fixed).

How does that sound?

If anyone wants to make non-trivial changes in ‘core-updates’, let’s
make them as early as possible.

I for one would like to finally merge ‘wip-build-systems-gexp’ so I’ll
try to do that.  There’s also support for response files in
‘ld-wrapper’, but that is easier (see <https://bugs.gnu.org/25882>).

Last but not least: who wants to be the timekeeper?  The position mostly
consists in firmly reminding people of the schedule.  :-)

Ludo’.

Re: ‘core-updates’ schedule

[Leo Famulari]

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

Re: ‘core-updates’ schedule

[Ludovic Courtès]

Heya!

Leo Famulari <leo@famulari.name> 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’.

Re: ‘core-updates’ schedule

[Leo Famulari]

On Fri, Apr 07, 2017 at 05:22:13PM +0200, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > On Thu, Apr 06, 2017 at 10:34:29AM +0200, Ludovic Courtès wrote:
> >> 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.
> 
> 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.

Agreed, we should try to stick to your suggested schedule this time. I'm
not trying to discourage anyone :) Just sharing my experience of what
sort of problems we can expect, for those who haven't paid close
attention to a core-updates cycle before.

Re: ‘core-updates’ schedule

[ng0]

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