unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* Release 1.2.1: timeline
@ 2021-03-12 15:00 zimoun
  2021-03-15 16:55 ` Ludovic Courtès
  0 siblings, 1 reply; 9+ messages in thread
From: zimoun @ 2021-03-12 15:00 UTC (permalink / raw)
  To: Guix Devel

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Release 1.2.1: timeline
  2021-03-12 15:00 Release 1.2.1: timeline zimoun
@ 2021-03-15 16:55 ` Ludovic Courtès
  2021-03-15 17:08   ` Vincent Legoll
  2021-03-15 18:14   ` Leo Famulari
  0 siblings, 2 replies; 9+ messages in thread
From: Ludovic Courtès @ 2021-03-15 16:55 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Release 1.2.1: timeline
  2021-03-15 16:55 ` Ludovic Courtès
@ 2021-03-15 17:08   ` Vincent Legoll
  2021-03-15 18:14   ` Leo Famulari
  1 sibling, 0 replies; 9+ messages in thread
From: Vincent Legoll @ 2021-03-15 17:08 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Release 1.2.1: timeline
  2021-03-15 16:55 ` Ludovic Courtès
  2021-03-15 17:08   ` Vincent Legoll
@ 2021-03-15 18:14   ` Leo Famulari
  2021-03-15 20:15     ` Vincent Legoll
                       ` (2 more replies)
  1 sibling, 3 replies; 9+ messages in thread
From: Leo Famulari @ 2021-03-15 18:14 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Release 1.2.1: timeline
  2021-03-15 18:14   ` Leo Famulari
@ 2021-03-15 20:15     ` Vincent Legoll
  2021-03-15 20:27     ` Leo Famulari
  2021-03-17 17:28     ` armhf-linux substitutes Ludovic Courtès
  2 siblings, 0 replies; 9+ messages in thread
From: Vincent Legoll @ 2021-03-15 20:15 UTC (permalink / raw)
  To: Leo Famulari; +Cc: Guix Devel

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Release 1.2.1: timeline
  2021-03-15 18:14   ` Leo Famulari
  2021-03-15 20:15     ` Vincent Legoll
@ 2021-03-15 20:27     ` Leo Famulari
  2021-03-17 17:28     ` armhf-linux substitutes Ludovic Courtès
  2 siblings, 0 replies; 9+ messages in thread
From: Leo Famulari @ 2021-03-15 20:27 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* armhf-linux substitutes
  2021-03-15 18:14   ` Leo Famulari
  2021-03-15 20:15     ` Vincent Legoll
  2021-03-15 20:27     ` Leo Famulari
@ 2021-03-17 17:28     ` Ludovic Courtès
  2021-03-17 18:56       ` zimoun
  2021-03-29  7:21       ` Mathieu Othacehe
  2 siblings, 2 replies; 9+ messages in thread
From: Ludovic Courtès @ 2021-03-17 17:28 UTC (permalink / raw)
  To: Leo Famulari; +Cc: Guix Devel, Mathieu Othacehe

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: armhf-linux substitutes
  2021-03-17 17:28     ` armhf-linux substitutes Ludovic Courtès
@ 2021-03-17 18:56       ` zimoun
  2021-03-29  7:21       ` Mathieu Othacehe
  1 sibling, 0 replies; 9+ messages in thread
From: zimoun @ 2021-03-17 18:56 UTC (permalink / raw)
  To: Ludovic Courtès, Leo Famulari; +Cc: Guix Devel, Mathieu Othacehe

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: armhf-linux substitutes
  2021-03-17 17:28     ` armhf-linux substitutes Ludovic Courtès
  2021-03-17 18:56       ` zimoun
@ 2021-03-29  7:21       ` Mathieu Othacehe
  1 sibling, 0 replies; 9+ messages in thread
From: Mathieu Othacehe @ 2021-03-29  7:21 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, zimoun


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


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-03-29  7:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-12 15:00 Release 1.2.1: timeline zimoun
2021-03-15 16:55 ` Ludovic Courtès
2021-03-15 17:08   ` Vincent Legoll
2021-03-15 18:14   ` Leo Famulari
2021-03-15 20:15     ` Vincent Legoll
2021-03-15 20:27     ` Leo Famulari
2021-03-17 17:28     ` armhf-linux substitutes Ludovic Courtès
2021-03-17 18:56       ` zimoun
2021-03-29  7:21       ` Mathieu Othacehe

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git