[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New 'version-1.3.0' branch and lifting string freeze on master
From: |
Maxim Cournoyer |
Subject: |
Re: New 'version-1.3.0' branch and lifting string freeze on master |
Date: |
Sun, 18 Apr 2021 08:08:00 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
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