Release 1.2.1: timeline

Release 1.2.1: timeline

[zimoun]

Hi,

The plan is to release on the April, 18th.  It is a target date.

This 1.2.1 release will mainly contain bunch of bug fixes and package
updates.  More, remove of Python 2 when possible.

Releasing is a good occasion to take the time to ungraft and test the
installers.


Ungrafting should break packages.  It is somehow unexpected but it could
happen that’s why it needs some tests and care.  Leo wrote how to help
here:

   <https://yhetil.org/guix/YEEv8IslFlTpqT0r@jasmine.lan>

and the branch wip-next-release already contains fixes.  Please check it
out and feedback is welcome.

We are planning an «ungraftathon» the last week-end of March (27-28).
Please roam on #guix if you want to help.

Python 2 removal needs some love.  Maxim described how they is doing
here:

   <https://yhetil.org/guix/87pn1oxv0m.fsf@gmail.com>

and a set of candidates is listed there:

   <https://yhetil.org/guix/86r1kmbsz1.fsf@gmail.com>


That’s said, you have in your tree any package update, it is the good
time to submit them. :-)

In addition, any bug fix is welcome.  Closing old ones are very welcome! :-)


A draft of the timeline is:

 - until April 1rst: fixes, check substitute availability, etc.
 - as soon as possible: start to build wip-next-release
 - merge branch wip-next-release when ready
 - on Monday 12th April, string freeze
 - couple of days after, branch the release and write the materials
   (ChangeLog and posts)
 - release

The architecture armf will not be included.  The branch core-updates
will not be merged.  Once this release is done, we could write a
timeline for the next core-updates merge and list what should be
included in the next release (1.2.2 or 1.3).  Somehow, all this is an
“experiment” for a webpage detailing the different timelines.

Does it make sense?


Cheers,
simon

Re: Release 1.2.1: timeline

[Ludovic Courtès]

Hello!

zimoun <zimon.toutoune@gmail.com> skribis:

> The plan is to release on the April, 18th.  It is a target date.

I want to believe!  :-)

> We are planning an «ungraftathon» the last week-end of March (27-28).
> Please roam on #guix if you want to help.

+1

> A draft of the timeline is:
>
>  - until April 1rst: fixes, check substitute availability, etc.
>  - as soon as possible: start to build wip-next-release
>  - merge branch wip-next-release when ready
>  - on Monday 12th April, string freeze
>  - couple of days after, branch the release and write the materials
>    (ChangeLog and posts)
>  - release

Sounds reasonable to me.

> The architecture armf will not be included.

Wait wait, I missed that.  What happened?  I think we should include it,
even if substitute availability remains low.

> The branch core-updates will not be merged.

Yeah, that sounds like the most reasonable approach.

> Once this release is done, we could write a timeline for the next
> core-updates merge and list what should be included in the next
> release (1.2.2 or 1.3).  Somehow, all this is an “experiment” for a
> webpage detailing the different timelines.
>
> Does it make sense?

It does.  Thanks for helping us stay on track!

Ludo’.

Re: Release 1.2.1: timeline

[Vincent Legoll]

Hello,

On Mon, Mar 15, 2021 at 5:55 PM Ludovic Courtès <ludo@gnu.org> wrote:
> > The architecture armf will not be included.
>
> Wait wait, I missed that.  What happened?  I think we should include it,
> even if substitute availability remains low.

IMHO, substitute availability should not be an inclusion criteria

-- 
Vincent Legoll

Re: Release 1.2.1: timeline

[Leo Famulari]

On Mon, Mar 15, 2021 at 05:55:21PM +0100, Ludovic Courtès wrote:
> > The architecture armf will not be included.
> 
> Wait wait, I missed that.  What happened?  I think we should include it,
> even if substitute availability remains low.

I had asked about the status of the armhf branch on #guix when a few of
us were trying to "tie up loose ends" for this release.

I don't have an opinion one way or the other, but since we are not
building substitutes for it at all, we should include in the release
announcement a clear description of the level of support that users can
expect.

Re: Release 1.2.1: timeline

[Vincent Legoll]

Hello,

On Mon, Mar 15, 2021 at 7:50 PM Leo Famulari <leo@famulari.name> wrote:
> we should include in the release announcement a clear description of
> the level of support that users can expect.

Yes, that would be useful too, I'm all for giving people the information that
it may not be easily usable, but still providing what we have now so that
any one can try to push it a bit further.

-- 
Vincent Legoll

Re: Release 1.2.1: timeline

[Leo Famulari]

On Mon, Mar 15, 2021 at 02:14:52PM -0400, Leo Famulari wrote:
> On Mon, Mar 15, 2021 at 05:55:21PM +0100, Ludovic Courtès wrote:
> > > The architecture armf will not be included.
> > 
> > Wait wait, I missed that.  What happened?  I think we should include it,
> > even if substitute availability remains low.
> 
> I had asked about the status of the armhf branch on #guix when a few of
> us were trying to "tie up loose ends" for this release.

I'm not sure why I wrote "armhf branch". I meant to refer to the armhf
port of Guix.

armhf-linux substitutes

[Ludovic Courtès]

Hi,

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Mar 15, 2021 at 05:55:21PM +0100, Ludovic Courtès wrote:
>> > The architecture armf will not be included.
>> 
>> Wait wait, I missed that.  What happened?  I think we should include it,
>> even if substitute availability remains low.
>
> I had asked about the status of the armhf branch on #guix when a few of
> us were trying to "tie up loose ends" for this release.
>
> I don't have an opinion one way or the other, but since we are not
> building substitutes for it at all, we should include in the release
> announcement a clear description of the level of support that users can
> expect.

Right, we could adjust the text in the “GNU Distribution” node of the
manual (we did that before when mips64el-linux was supported without
substitutes.)

Mathieu, what’s preventing us from doing armhf-linux builds again?  We
could use the OverDrives for that (with an upper bound though), along
with the SBCs in machines-for-berlin.scm.

That won’t be enough to keep up, so perhaps we’ll have to restrict
armhf-linux builds to the “core” subset or the release-manifest.scm.

Thoughts?

Ludo’.

Re: armhf-linux substitutes

[zimoun]

Hi,

On Wed, 17 Mar 2021 at 18:28, Ludovic Courtès <ludo@gnu.org> wrote:

> Mathieu, what’s preventing us from doing armhf-linux builds again?  We
> could use the OverDrives for that (with an upper bound though), along
> with the SBCs in machines-for-berlin.scm.

We should start to build ASAP…

> That won’t be enough to keep up, so perhaps we’ll have to restrict
> armhf-linux builds to the “core” subset or the release-manifest.scm.

…to have the time to effectively build and probably fix this at least
“core” subset.


Naive question, how can I emulated without X this architecture?


Cheers,
simon

Re: armhf-linux substitutes

[Mathieu Othacehe]

Hello,

> Mathieu, what’s preventing us from doing armhf-linux builds again?  We
> could use the OverDrives for that (with an upper bound though), along
> with the SBCs in machines-for-berlin.scm.
>
> That won’t be enough to keep up, so perhaps we’ll have to restrict
> armhf-linux builds to the “core” subset or the release-manifest.scm.

With emulating builds performing badly, I'm considering building only the
'core subset for armhf and aarch64 and only on native hardware. That
would require to have the other overdrives up & running I guess.

Thanks,

Mathieu