Re: Release v1.4 (or 2.0): process and schedule ?

[Chris Marusich]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> About the current status, I'm nearing on pushing a version-1.4.0 branch
> which is based on master with a few more (core-ish) updates.  There's
> still a few days ahead of that, so if you manage to get many of this
> kind of problems fixed & merged in master they can easily be included in
> the next release.

There is a problem that currently prevents "guix pull" from succeeding
for powerpc64le-linux on master.  I'd like to resolve it before the
release if possible.  The problem is here, including a patch to fix it:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940

This patch is relatively simple, but it will rebuild many packages for
all architectures because it modifies guix/build/gremlin.scm, which is
used by the gnu-build-system.  How can I integrate this change into the
1.4.0 release?

Normally I would commit such a change to core-updates.  However, if I do
that, then the change probably won't make it into master or the
version-1.4.0 branch in time.  Is there an opportunity to put the change
somewhere so that it will make it into the release?  I'm not sure.

Here's my proposal.  Since the bug may very well be benign, I could
apply a simple work-around to master that just skips the failing test on
powerpc64le-linux.  I could then apply the actual fix to core-updates.
Later, after master has been merged to core-updates, I could re-enable
the test on core-updates.  This would allow "guix pull" to succeed for
powerpc64le-linux on master without rebuilding the world, and the
correct fix would still be applied on core-updates for a later release.

Do you think that would work?

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836

signature.asc
Description: PGP signature