* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-20 2:12 ` Maxim Cournoyer
@ 2021-12-20 3:43 ` raingloom
2021-12-20 9:04 ` zimoun
` (2 subsequent siblings)
3 siblings, 0 replies; 22+ messages in thread
From: raingloom @ 2021-12-20 3:43 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Guix Devel
On Sun, 19 Dec 2021 21:12:36 -0500
Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> Hi Simon,
>
> zimoun <zimon.toutoune@gmail.com> writes:
>
> > Hi,
> >
> > Now core-updates-frozen is merged. Now The Big Change [1 ]is done.
> > Do we go for v1.4 or v2.0?
>
> As I've mentioned previously, I'd go for a 1.4.0 release, since
> overall we've refined and improved (greatly!) what we already had
> rather than introduced something revolutionary. I'd keep a 2.0.0 for
> when we have p2p distributed substitutes, a custom graphical tool
> and/or integration with the 'Software' application in GNOME, this
> kind of big user-facing changes. But that's just my personal opinion
> :-). If the majority feels a 2.0.0 is more suitable, I won't mind.
Agreed, if we go by something like semver.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-20 2:12 ` Maxim Cournoyer
2021-12-20 3:43 ` raingloom
@ 2021-12-20 9:04 ` zimoun
2021-12-20 9:14 ` zimoun
2021-12-20 21:24 ` Ludovic Courtès
2021-12-20 18:12 ` Bengt Richter
2021-12-21 20:48 ` Vagrant Cascadian
3 siblings, 2 replies; 22+ messages in thread
From: zimoun @ 2021-12-20 9:04 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Guix Devel
Hi Maxim,
On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do
>> we go for v1.4 or v2.0?
>
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary. I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes. But that's just my personal opinion :-). If the majority
> feels a 2.0.0 is more suitable, I won't mind.
I do not have a strong opinion either. On the other hand, all the
changes are incremental over a relatively large period of time, other
said, each change is not revolutionary but all in all, they can be
considered as. The revolution of the Sun is made by 365 small changes
and each day compared one by one looks really similar – aside climate
change or tropical/equatorial latitude – and at the end, seasons appear.
Anyway, I won’t mind equally. :-)
>> In both case, what is the target for a release date? I propose January
>> 31rst. WDYT?
>
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.
To me,
- adapt the importers with the new style is also a thing
- various guix home minor fixes discussed [1] by Xinglu, Andrew and
Ludo, a blog post would be neat too. :-)
1: <https://yhetil.org/guix/878rwlu4uz.fsf@inria.fr>
Cheers,
simon
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-20 9:04 ` zimoun
@ 2021-12-20 9:14 ` zimoun
2021-12-20 21:24 ` Ludovic Courtès
1 sibling, 0 replies; 22+ messages in thread
From: zimoun @ 2021-12-20 9:14 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Guix Devel
On Mon, 20 Dec 2021 at 10:04, zimoun <zimon.toutoune@gmail.com> wrote:
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
> - adapt the importers with the new style is also a thing
> - various guix home minor fixes discussed [1] by Xinglu, Andrew and
> Ludo, a blog post would be neat too. :-)
Also this:
http://issues.guix.gnu.org/issue/51319
Cheers,
simon
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-20 9:04 ` zimoun
2021-12-20 9:14 ` zimoun
@ 2021-12-20 21:24 ` Ludovic Courtès
2021-12-20 22:54 ` zimoun
1 sibling, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2021-12-20 21:24 UTC (permalink / raw)
To: zimoun; +Cc: Guix Devel, Maxim Cournoyer
Hi,
zimoun <zimon.toutoune@gmail.com> skribis:
> On Sun, 19 Dec 2021 at 21:12, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>
>>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do
>>> we go for v1.4 or v2.0?
>>
>> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
>> we've refined and improved (greatly!) what we already had rather than
>> introduced something revolutionary. I'd keep a 2.0.0 for when we have
>> p2p distributed substitutes, a custom graphical tool and/or integration
>> with the 'Software' application in GNOME, this kind of big user-facing
>> changes. But that's just my personal opinion :-). If the majority
>> feels a 2.0.0 is more suitable, I won't mind.
>
> I do not have a strong opinion either.
Same here. But first it’d be nice to come up with a summary of what we
did in ‘core-updates’ because I think we’ve all forgotten most of it.
:-)
[...]
>>> In both case, what is the target for a release date? I propose January
>>> 31rst. WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> To me,
>
> - adapt the importers with the new style is also a thing
> - various guix home minor fixes discussed [1] by Xinglu, Andrew and
> Ludo, a blog post would be neat too. :-)
Agreed on all this.
I’d also like to see if we can avoid the two-step “make release” process
by updating the ‘guix’ package once only.
And also see if we can arrange for ‘guix system init’ to hard-link files
instead of copying them during the normal installation process
(currently it copies files from /tmp to /gnu on the installation media).
Probably at some point we should open a bug for the release and mark
other items as blockers, like we did for the previous release. One of
us could then keep track of things and send weekly updates, say (it’s
best if it’s someone not too deeply involved with the actual release
hacks!).
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-20 2:12 ` Maxim Cournoyer
2021-12-20 3:43 ` raingloom
2021-12-20 9:04 ` zimoun
@ 2021-12-20 18:12 ` Bengt Richter
2021-12-21 20:48 ` Vagrant Cascadian
3 siblings, 0 replies; 22+ messages in thread
From: Bengt Richter @ 2021-12-20 18:12 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Guix Devel
Hi all,
On +2021-12-19 21:12:36 -0500, Maxim Cournoyer wrote:
> Hi Simon,
>
> zimoun <zimon.toutoune@gmail.com> writes:
>
> > Hi,
> >
> > Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do
> > we go for v1.4 or v2.0?
>
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary. I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes. But that's just my personal opinion :-). If the majority
> feels a 2.0.0 is more suitable, I won't mind.
>
> > In both case, what is the target for a release date? I propose January
> > 31rst. WDYT?
>
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.
>
> [...]
>
> >> The lesson of v1.0.1 [#,@] is: please help in testing the
> >> installer. :-)
>
> Yes, I also feel we should give the installer a lot of testing; it seems
> many people have had issues with it, especially when dealing with newer
> EFI machines. Unfortunately I don't have such a machine available for
> testing myself...
>
This seems, IIUC, like a FLOSS way to deliver multiple versions of guix
in the form of a collection of bootable ISOs in a single bootable image
for easy trial on various systems.
WDYT?
[0] https://www.theregister.com/2021/12/10/friday_foss_fest/?td=keepreading-btm
[1] git clone 'https://github.com/ventoy/Ventoy.git'
> >> How does it sound?
> >>
> >> Last, Guix is a “rolling-release“, so what does it mean ‘release’? :-)
> >> The main argument for releasing, IMHO, is communication and so attract
> >> potential new users. :-)
>
> To me, it's a milestone that can be communicated and provides a more
> thoroughly tested (in theory) Guix installation image.
>
> Thanks for helping shape the release plan,
>
> Maxim
>
--
Regards,
Bengt Richter
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-20 2:12 ` Maxim Cournoyer
` (2 preceding siblings ...)
2021-12-20 18:12 ` Bengt Richter
@ 2021-12-21 20:48 ` Vagrant Cascadian
2021-12-21 21:20 ` Vagrant Cascadian
2021-12-27 3:46 ` Maxim Cournoyer
3 siblings, 2 replies; 22+ messages in thread
From: Vagrant Cascadian @ 2021-12-21 20:48 UTC (permalink / raw)
To: Maxim Cournoyer, zimoun; +Cc: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
On 2021-12-19, Maxim Cournoyer wrote:
> zimoun <zimon.toutoune@gmail.com> writes:
>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do
>> we go for v1.4 or v2.0?
>
> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
> we've refined and improved (greatly!) what we already had rather than
> introduced something revolutionary. I'd keep a 2.0.0 for when we have
> p2p distributed substitutes, a custom graphical tool and/or integration
> with the 'Software' application in GNOME, this kind of big user-facing
> changes. But that's just my personal opinion :-). If the majority
> feels a 2.0.0 is more suitable, I won't mind.
>
>> In both case, what is the target for a release date? I propose January
>> 31rst. WDYT?
>
> I'd like to fix #52051 before issuing the first release candidate (RC).
> Assuming this can be made before the end of January with the first RC
> coming out around New Year, and that the kind of collaboration I've seen
> in the last weeks continues at the same intensity, this seems
> achievable.
Would it be appropriate to fix the ~700 low-hanbging fruit issues that
are identified by:
guix lint --checkers=description,synopsis
It is not the most exciting work technically, but it is relatively easy,
and low risk, maybe the worst it does is put a bit more work on
translators...
Maybe there are also other low hanging fruit guix lint knows about that
would not be particularly disruptive?
It is not particularly urgent for a release, per se, but I suspect it
will just grow and grow without some sort of cycle to address such
trivial issues... and doing such cleanup before making a release would
aim for a higher standard of craftspersonship. :)
I can maybe try to help stir up a coordinated effort, if folks are
interested in pursuing this line of thinking!
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-21 20:48 ` Vagrant Cascadian
@ 2021-12-21 21:20 ` Vagrant Cascadian
2022-01-03 14:31 ` Ludovic Courtès
2021-12-27 3:46 ` Maxim Cournoyer
1 sibling, 1 reply; 22+ messages in thread
From: Vagrant Cascadian @ 2021-12-21 21:20 UTC (permalink / raw)
To: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
On 2021-12-21, Vagrant Cascadian wrote:
> On 2021-12-19, Maxim Cournoyer wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>>> In both case, what is the target for a release date? I propose January
>>> 31rst. WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
> are identified by:
>
> guix lint --checkers=description,synopsis
>
> It is not the most exciting work technically, but it is relatively easy,
> and low risk, maybe the worst it does is put a bit more work on
> translators...
>
> Maybe there are also other low hanging fruit guix lint knows about that
> would not be particularly disruptive?
>
> It is not particularly urgent for a release, per se, but I suspect it
> will just grow and grow without some sort of cycle to address such
> trivial issues... and doing such cleanup before making a release would
> aim for a higher standard of craftspersonship. :)
>
>
> I can maybe try to help stir up a coordinated effort, if folks are
> interested in pursuing this line of thinking!
Could guix style be adapted to apply some of these changes? Some of them
are simple things like trailing whitespace, for example.
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-21 21:20 ` Vagrant Cascadian
@ 2022-01-03 14:31 ` Ludovic Courtès
2022-01-03 16:32 ` Vagrant Cascadian
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2022-01-03 14:31 UTC (permalink / raw)
To: Vagrant Cascadian; +Cc: Guix Devel
Hello!
Vagrant Cascadian <vagrant@debian.org> skribis:
> On 2021-12-21, Vagrant Cascadian wrote:
[...]
>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
>> are identified by:
>>
>> guix lint --checkers=description,synopsis
[...]
> Could guix style be adapted to apply some of these changes? Some of them
> are simple things like trailing whitespace, for example.
Trailing whitespace in synopses and descriptions? It sure could do
that¹. Even non-ambiguous issues like “This packages” I guess?
Thanks,
Ludo’.
¹ <https://issues.guix.gnu.org/52974> brings “styling rules”; we could
add styling rules for such things.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2022-01-03 14:31 ` Ludovic Courtès
@ 2022-01-03 16:32 ` Vagrant Cascadian
0 siblings, 0 replies; 22+ messages in thread
From: Vagrant Cascadian @ 2022-01-03 16:32 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Guix Devel
On 2022-01-03, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> On 2021-12-21, Vagrant Cascadian wrote:
>
> [...]
>
>>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
>>> are identified by:
>>>
>>> guix lint --checkers=description,synopsis
>
> [...]
>
>> Could guix style be adapted to apply some of these changes? Some of them
>> are simple things like trailing whitespace, for example.
>
> Trailing whitespace in synopses and descriptions? It sure could do
> that¹. Even non-ambiguous issues like “This packages” I guess?
...
> ¹ <https://issues.guix.gnu.org/52974> brings “styling rules”; we could
> add styling rules for such things.
I also suspect that a majority of the problems I recently fixed were
introduced by using importers; could guix style and/or guix lint be
integrated with the importers too?
live well,
vagrant
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-21 20:48 ` Vagrant Cascadian
2021-12-21 21:20 ` Vagrant Cascadian
@ 2021-12-27 3:46 ` Maxim Cournoyer
2022-01-03 14:33 ` Ludovic Courtès
` (2 more replies)
1 sibling, 3 replies; 22+ messages in thread
From: Maxim Cournoyer @ 2021-12-27 3:46 UTC (permalink / raw)
To: Vagrant Cascadian; +Cc: Guix Devel
Hi Vagrant,
Vagrant Cascadian <vagrant@debian.org> writes:
> On 2021-12-19, Maxim Cournoyer wrote:
>> zimoun <zimon.toutoune@gmail.com> writes:
>>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do
>>> we go for v1.4 or v2.0?
>>
>> As I've mentioned previously, I'd go for a 1.4.0 release, since overall
>> we've refined and improved (greatly!) what we already had rather than
>> introduced something revolutionary. I'd keep a 2.0.0 for when we have
>> p2p distributed substitutes, a custom graphical tool and/or integration
>> with the 'Software' application in GNOME, this kind of big user-facing
>> changes. But that's just my personal opinion :-). If the majority
>> feels a 2.0.0 is more suitable, I won't mind.
>>
>>> In both case, what is the target for a release date? I propose January
>>> 31rst. WDYT?
>>
>> I'd like to fix #52051 before issuing the first release candidate (RC).
>> Assuming this can be made before the end of January with the first RC
>> coming out around New Year, and that the kind of collaboration I've seen
>> in the last weeks continues at the same intensity, this seems
>> achievable.
>
> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
> are identified by:
>
> guix lint --checkers=description,synopsis
>
> It is not the most exciting work technically, but it is relatively easy,
> and low risk, maybe the worst it does is put a bit more work on
> translators...
>
> Maybe there are also other low hanging fruit guix lint knows about that
> would not be particularly disruptive?
>
> It is not particularly urgent for a release, per se, but I suspect it
> will just grow and grow without some sort of cycle to address such
> trivial issues... and doing such cleanup before making a release would
> aim for a higher standard of craftspersonship. :)
About the current status, I'm nearing on pushing a version-1.4.0 branch
which is based on master with a few more (core-ish) updates. There's
still a few days ahead of that, so if you manage to get many of this
kind of problems fixed & merged in master they can easily be included in
the next release.
HTH,
Maxim
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-27 3:46 ` Maxim Cournoyer
@ 2022-01-03 14:33 ` Ludovic Courtès
2022-01-04 16:24 ` Maxim Cournoyer
2022-01-04 19:32 ` Chris Marusich
2022-01-15 19:26 ` Vagrant Cascadian
2 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2022-01-03 14:33 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Vagrant Cascadian, Guix Devel
Hello!
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> About the current status, I'm nearing on pushing a version-1.4.0 branch
> which is based on master with a few more (core-ish) updates. There's
> still a few days ahead of that, so if you manage to get many of this
> kind of problems fixed & merged in master they can easily be included in
> the next release.
Before the first RC, I’d like to push the latest ‘guix style’ changes:
<https://issues.guix.gnu.org/52974>.
Do we enter string freeze before the first RC? I forgot how we did it
last time.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2022-01-03 14:33 ` Ludovic Courtès
@ 2022-01-04 16:24 ` Maxim Cournoyer
0 siblings, 0 replies; 22+ messages in thread
From: Maxim Cournoyer @ 2022-01-04 16:24 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Vagrant Cascadian, Guix Devel
Hello,
Ludovic Courtès <ludo@gnu.org> writes:
> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>> which is based on master with a few more (core-ish) updates. There's
>> still a few days ahead of that, so if you manage to get many of this
>> kind of problems fixed & merged in master they can easily be included in
>> the next release.
>
> Before the first RC, I’d like to push the latest ‘guix style’ changes:
> <https://issues.guix.gnu.org/52974>.
>
> Do we enter string freeze before the first RC? I forgot how we did it
> last time.
I remember the string freeze was a bit early last time, given the
release also took time to be polished and shipped, but I think it also
was useful. Integrating translation changes should occur not too late
as they can introduce build issues that need to be resolved, blocking a
release.
Thank you,
Maxim
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-27 3:46 ` Maxim Cournoyer
2022-01-03 14:33 ` Ludovic Courtès
@ 2022-01-04 19:32 ` Chris Marusich
2022-01-06 13:49 ` Maxim Cournoyer
2022-01-15 19:26 ` Vagrant Cascadian
2 siblings, 1 reply; 22+ messages in thread
From: Chris Marusich @ 2022-01-04 19:32 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Vagrant Cascadian, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> About the current status, I'm nearing on pushing a version-1.4.0 branch
> which is based on master with a few more (core-ish) updates. There's
> still a few days ahead of that, so if you manage to get many of this
> kind of problems fixed & merged in master they can easily be included in
> the next release.
There is a problem that currently prevents "guix pull" from succeeding
for powerpc64le-linux on master. I'd like to resolve it before the
release if possible. The problem is here, including a patch to fix it:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940
This patch is relatively simple, but it will rebuild many packages for
all architectures because it modifies guix/build/gremlin.scm, which is
used by the gnu-build-system. How can I integrate this change into the
1.4.0 release?
Normally I would commit such a change to core-updates. However, if I do
that, then the change probably won't make it into master or the
version-1.4.0 branch in time. Is there an opportunity to put the change
somewhere so that it will make it into the release? I'm not sure.
Here's my proposal. Since the bug may very well be benign, I could
apply a simple work-around to master that just skips the failing test on
powerpc64le-linux. I could then apply the actual fix to core-updates.
Later, after master has been merged to core-updates, I could re-enable
the test on core-updates. This would allow "guix pull" to succeed for
powerpc64le-linux on master without rebuilding the world, and the
correct fix would still be applied on core-updates for a later release.
Do you think that would work?
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2022-01-04 19:32 ` Chris Marusich
@ 2022-01-06 13:49 ` Maxim Cournoyer
2022-01-09 2:21 ` Chris Marusich
0 siblings, 1 reply; 22+ messages in thread
From: Maxim Cournoyer @ 2022-01-06 13:49 UTC (permalink / raw)
To: Chris Marusich; +Cc: Vagrant Cascadian, Guix Devel
Hello Chris,
Chris Marusich <cmmarusich@gmail.com> writes:
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>> which is based on master with a few more (core-ish) updates. There's
>> still a few days ahead of that, so if you manage to get many of this
>> kind of problems fixed & merged in master they can easily be included in
>> the next release.
>
> There is a problem that currently prevents "guix pull" from succeeding
> for powerpc64le-linux on master. I'd like to resolve it before the
> release if possible. The problem is here, including a patch to fix it:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940
>
> This patch is relatively simple, but it will rebuild many packages for
> all architectures because it modifies guix/build/gremlin.scm, which is
> used by the gnu-build-system. How can I integrate this change into the
> 1.4.0 release?
>
> Normally I would commit such a change to core-updates. However, if I do
> that, then the change probably won't make it into master or the
> version-1.4.0 branch in time. Is there an opportunity to put the change
> somewhere so that it will make it into the release? I'm not sure.
>
> Here's my proposal. Since the bug may very well be benign, I could
> apply a simple work-around to master that just skips the failing test on
> powerpc64le-linux. I could then apply the actual fix to core-updates.
> Later, after master has been merged to core-updates, I could re-enable
> the test on core-updates. This would allow "guix pull" to succeed for
> powerpc64le-linux on master without rebuilding the world, and the
> correct fix would still be applied on core-updates for a later release.
>
> Do you think that would work?
Since the version-1.4.0 branch I've been polishing locally still hasn't
been published nor built, there's still time to apply the patch without
any consideration for world rebuilds to that branch (at this point we
want the changes to be low risk ones though, but that sounds like one).
Thanks,
Maxim
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2022-01-06 13:49 ` Maxim Cournoyer
@ 2022-01-09 2:21 ` Chris Marusich
2022-01-18 5:05 ` Maxim Cournoyer
0 siblings, 1 reply; 22+ messages in thread
From: Chris Marusich @ 2022-01-09 2:21 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Vagrant Cascadian, Guix Devel
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
Hi Maxim,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hello Chris,
>
> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>
>>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>>> which is based on master with a few more (core-ish) updates. There's
>>> still a few days ahead of that, so if you manage to get many of this
>>> kind of problems fixed & merged in master they can easily be included in
>>> the next release.
>>
>> There is a problem that currently prevents "guix pull" from succeeding
>> for powerpc64le-linux on master. I'd like to resolve it before the
>> release if possible. The problem is here, including a patch to fix it:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940
>>
>> [...]
>
> Since the version-1.4.0 branch I've been polishing locally still hasn't
> been published nor built, there's still time to apply the patch without
> any consideration for world rebuilds to that branch (at this point we
> want the changes to be low risk ones though, but that sounds like one).
With Ludo's feedback, I was able to fix 52940 without rebuilding the
world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master. Can
you try merging master into your version-1.4.0 branch?
At this point in time, I'm unaware of any issues that would be
show-stoppers for for powerpc64le-linux. As a reminder, issues
important to powerpc64le-linux can be seen by searching for issues
tagged with the "guix" user's powerpc64le-linux Debbugs usertag:
https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix
I'll keep my eye out for other potential powerpc64le-linux issues and
see what I can do to help in the days/weeks to come.
Now that the "guix" package is building successfully again on master, I
can finally build up-to-date versions of cuirass and
guix-build-coordinator. Although it isn't directly related to the
release, I think I will resume my efforts to add a new powerpc64le-linux
node to the build farm.
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2022-01-09 2:21 ` Chris Marusich
@ 2022-01-18 5:05 ` Maxim Cournoyer
2022-01-18 13:20 ` Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: Maxim Cournoyer @ 2022-01-18 5:05 UTC (permalink / raw)
To: Chris Marusich; +Cc: Vagrant Cascadian, Guix Devel
Hi Chris,
Chris Marusich <cmmarusich@gmail.com> writes:
[...]
> With Ludo's feedback, I was able to fix 52940 without rebuilding the
> world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master. Can
> you try merging master into your version-1.4.0 branch?
Awesome! As you may have noticed, today version-1.4.0 was merged back
into master.
> At this point in time, I'm unaware of any issues that would be
> show-stoppers for for powerpc64le-linux. As a reminder, issues
> important to powerpc64le-linux can be seen by searching for issues
> tagged with the "guix" user's powerpc64le-linux Debbugs usertag:
>
> https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix
>
> I'll keep my eye out for other potential powerpc64le-linux issues and
> see what I can do to help in the days/weeks to come.
Thanks for keeping these powerpc64le issues in check!
Cheers,
Maxim
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Release v1.4 (or 2.0): process and schedule ?
2021-12-27 3:46 ` Maxim Cournoyer
2022-01-03 14:33 ` Ludovic Courtès
2022-01-04 19:32 ` Chris Marusich
@ 2022-01-15 19:26 ` Vagrant Cascadian
2 siblings, 0 replies; 22+ messages in thread
From: Vagrant Cascadian @ 2022-01-15 19:26 UTC (permalink / raw)
To: Maxim Cournoyer; +Cc: Guix Devel
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]
On 2021-12-26, Maxim Cournoyer wrote:
> Vagrant Cascadian <vagrant@debian.org> writes:
>> On 2021-12-19, Maxim Cournoyer wrote:
>>> zimoun <zimon.toutoune@gmail.com> writes:
>>>> Now core-updates-frozen is merged. Now The Big Change [1 ]is done. Do
>>>> we go for v1.4 or v2.0?
...
>> Would it be appropriate to fix the ~700 low-hanbging fruit issues that
>> are identified by:
>>
>> guix lint --checkers=description,synopsis
>>
>> It is not the most exciting work technically, but it is relatively easy,
>> and low risk, maybe the worst it does is put a bit more work on
>> translators...
>>
>> Maybe there are also other low hanging fruit guix lint knows about that
>> would not be particularly disruptive?
>>
>> It is not particularly urgent for a release, per se, but I suspect it
>> will just grow and grow without some sort of cycle to address such
>> trivial issues... and doing such cleanup before making a release would
>> aim for a higher standard of craftspersonship. :)
>
> About the current status, I'm nearing on pushing a version-1.4.0 branch
> which is based on master with a few more (core-ish) updates. There's
> still a few days ahead of that, so if you manage to get many of this
> kind of problems fixed & merged in master they can easily be included in
> the next release.
I managed to get ~150 fixes in before version-1.4.0 was merged...
Wondering if it would be possible to also merge or cherry-pick:
757a7978dd3de98d5bb033d27fd5a613038b4dc5
gnu: trytond-*: Fix grammar.
3c43f2b4f54dead73ce19427eb1e364581b7f2e0
gnu: julia-bioalignments: Fix spelling.
That would fix a few more of these sorts of issues, and only affects
synopsis and description strings in small ways.
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread