Re: Release 1.2.1: timeline

2021-03-15 Thread 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.



Re: Release 1.2.1: timeline

2021-03-15 Thread Vincent Legoll
Hello,

On Mon, Mar 15, 2021 at 7:50 PM Leo Famulari  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

2021-03-15 Thread 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

2021-03-15 Thread Vincent Legoll
Hello,

On Mon, Mar 15, 2021 at 5:55 PM 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.

IMHO, substitute availability should not be an inclusion criteria

-- 
Vincent Legoll



Re: Release 1.2.1: timeline

2021-03-15 Thread Ludovic Courtès
Hello!

zimoun  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’.



Release 1.2.1: timeline

2021-03-12 Thread 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:

   

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:

   

and a set of candidates is listed there:

   


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