Re: New 'version-1.3.0' branch and lifting string freeze on master

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> With the remaining issues to be tackled for the current release (v1.3.0)
>> due tomorrow, I think we may need a bit of extra time to fix them and do
>> more testing.  These are the remaining issues (obtained by pressing the
>> 'b' key in Emacs Debbugs while visiting the parent issue with
>> 'debbugs-gnu-bugs RET 47297 RET').  The release task issue can also be
>> viewed at https://issues.guix.gnu.org/47297.
>>
>> 47808 important  Bone Baboon        guile-git-0.5.0.drv build failed on i686-linux
>> 47567 important  Alexandru-Sergiu M Installer crash in 'uuid->string' for a FAT16 partition
>> 44872 important  Tim Magee          GuixSD 1.2.0 installer fails with exception when formatting drive
>> 33848 important  Ludovic Courtès    Store references in SBCL-compiled code are "invisible"
>> 47841 normal     Julien Lepiller    [release 1.2.1] could not install on foreign distro
>> 47745 normal     Mathieu Othacehe   ldap test is failing
>> 47744 normal     Mathieu Othacehe   nfs-root-fs test is failing
>
> I agree that we need a bit more time to address these, hopefully get
> ‘wip-ungrafting’ merged, and above all get more testing.

Yes, as discussed on IRC with lfam,  I suggested we try to include the
changes of that branch in version-1.3.0.

> There are other items from doc/release.org in maintenance.git that will
> have to be addressed, such as the dreaded NEWS update and companion blog
> post.

Indeed; my idea for this is to have a WIP commit that I'll publish at
the top of version-1.3.0 and others can use it as a base and send
patches to the mailing list.  I've experimented yesterday with the 'make
update-NEWS' target and it was modifying the 1.2.0 items although I've
added a skeleton for 1.3.0 in the NEWS file already.

>> To avoid keep master in string freeze longer, I've now created the
>> 'release-v1.3.0' branch where the fixes for the remaining blocking
>> issues should go.
>
> Nitpick: could we rename it to ‘version-1.3.0’, similar to the previous
> release branches?

It was a typo on my part, the name is actually 'version-1.3.0' :-).

> BTW, are we going for 1.3.0 rather than 1.2.1?  I’m fine either way,
> it’s true that 1.3.0 might better reflect the amount of work that has
> gone into it…

Yes, this was a change I proposed.  I wasn't sure if there was a good
reason for 1.2.1 but the rationale is indeed that that 1.3.0 reflects
better on the amount of changes (including new features) that went in
this release.

>> I'll now attempt to produce a first release candidate (RC) via the
>> release tooling.
>
> Yay!  If we eventually merge ‘wip-ungrafting’, we should have at least
> one RC built with that branch merged.

OK! Sounds good, thank you!

Maxim