Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Hi, > > Maxim Cournoyer <maxim.courno...@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