Re: Release on April 18th?

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Fri, 05 Mar 2021 at 14:27, Leo Famulari <leo@famulari.name> wrote:
> On Fri, Mar 05, 2021 at 03:31:22PM +0100, Andreas Enge wrote:

>> it would be nice if core-updates could be part of the release. I have
>> been waiting for gmp, mpfr and mpc to appear in master. In particular
>> mpfr-4.1.0 has been released in July 2020, and I have updated it in
>> core-updates in the same month. Even with a release in April, that makes
>> 9 months! Otherwise, we would end very far off the 6 months suggested in
>> doc/contributing.texi.
>> 
>> If I read the git history correctly, we have merged core-updates for the
>> last time in May 2020. Shocking numbers. Hopefully the recent progress
>> in continuous integration will help us reach our goal of more frequent
>> merging again.
>
> I agree, it's a long time without core-updates. Guix could complete
> core-updates in time for April 18, at least for x86_64, if many people
> work on it.

On #guix, I proposed [1] without an answer (yet :-)):

        what is the current blocking for merging core-updates? I mean
        the last merge seems from May 2020. If all the branch is not in
        a state to be mergeable, maybe we could simply merge a part of
        it. WDYT?

1: <http://logs.guix.gnu.org/guix/2021-03-05.log#194536>


> Simon, is there a reason you chose April 18 for the release? Or could we
> choose a later date?

Because a) it is ~6 months later than previous one and I think releasing
twice a year is the process we should adopt, b) it is an anniversary
(first commit) and by chance the other anniversary (first public
announce on Nov. 23rd) is spaced by ~6 month.

However, I think it is a bad idea to postpone and wait for core-updates
merge.  We should fix deadlines for releasing everything ~6 months and
simply make it happen.  IMHO.

In my views, since Guix is a rolling release, adding tags is more about
public announcement than “features“, i.e., attract users and communicate
about the new stuff.  Therefore, merging core-updates before a release
could be cool because it increases the list of new stuff but this merge
is not mandatory.  Once the user is in, ’guix pull’ provides what is in
core-updates whenever the merge is.  And what is in core-updates will be
advertised at the next release (~6 months later).

(Releasing every ~3 months should be even better but we do not have the
task force to make it.)


That’s said, when could core-update be merged to master?  What could be
the deadline?  From my point of view, delaying a couple (meaning 2 or 3
here ;-)) of weeks from April 18th sounds fine with me.

Even, from my understanding, we should minor release ASAP, e.g., on
April 18th or even before if possible.  And we could also plan to
release (major or minor) after the core-updates merge (say in June).
Then on Nov. 23rd, I think it could be nice to have another release.
Well, since Guix is rolling-release, releasing should be smooth.


BTW, I sympathize with the frustration about core-updates not merged
since last May.  On the other hand, I did nothing to help in the merging
process. :-(  Maybe, we could organize a hackathon or synchronize a
core-updates week: freeze the branch and address issues.  WDYT?

Cheers,
simon