Re: Planning for a release, for real

[zimoun]

Hi,

On jeu., 06 oct. 2022 at 16:50, Ludovic Courtès  wrote:

>   • Update NEWS (mostly done already!), prepare a blog post listing the
> highlights and linking to the relevant material.  (See
>  for inspiration.)

Just a reminder about ’guix environment’:

--8<---cut here---start->8---
@quotation Deprecation warning
The @command{guix environment} command is deprecated in favor of
@command{guix shell}, which performs similar functions but is more
convenient to use.  @xref{Invoking guix shell}.

Being deprecated, @command{guix environment} is slated for eventual
removal, but the Guix project is committed to keeping it until May 1st,
2023.  Please get in touch with us at @email{guix-devel@@gnu.org} if you
would like to discuss it.
@end quotation
--8<---cut here---end--->8---

Therefore, it would appear helpful to mention that for this future
release.  Because May 1st, 2023 is… soon! :-)


Cheers,
simon

Re: Planning for a release, for real

[Julien Lepiller]

It depends on the language, I'd say a week is good, maybe less as long as we 
can include a week-end (maybe it's personal, but I find more time to contribute 
in the week-ends).

Le 7 octobre 2022 11:49:21 GMT+02:00, "Ludovic Courtès"  a écrit :
>Hi,
>
>Julien Lepiller  skribis:
>
>> I'll take care of the cranslations (notifying translators, ensuring string 
>> freeze is respected, …)
>
>Great, thanks.
>
>> We need to be careful not to start the stsing freeze step too early. Last 
>> time (or previous?) we started a week before the scheduled release date, but 
>> the schedule slipped by a few weeks and we had some pressure in the pipeline 
>> because some patches could not be applied because of string changes.
>>
>> Let's try to have a better vision on the planning this time :)
>
>Right!  How long do you think we need for the string freeze?
>
>I feel that thanks to Weblate translations are continuously updated, so
>maybe things can be frozen for a shorter period of time?
>
>Thanks,
>Ludo’.

Re: Planning for a release, for real

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> Ludovic Courtès  writes:
>
>> We need to plan and coordinate.  Releases have to be a group effort;
>> some of the most important work won’t be coding but coordination.
>> Coordination is key.  I don’t think I should be spearheading that
>> effort, but I’m happy to be part of it.
>>
>> Who’s ready to commit time towards that goal for the coming weeks?
>>
>> Here’s a list of things to do to get there:
>>
>>   • Merge ‘staging’ (?).  What’s the status of that one, it seemed ready
>> a couple of weeks ago, but then I lost track of it.  Marius?
>>
>> We need a ‘staging’ champion to keep track of what’s left to be
>> done, reports progress, pings people, etc.  That person does not
>> have to be hacking like crazy, on the contrary!
>
> I'd like to get qa.guix.gnu.org to the point where it's useful for
> getting branches merged. Currently, it's possible to submit builds for
> branches, which is happening currently for staging.
>
> While that's great, the substitute availability for the branch is still
> poor [1], the builds are happening, but there's just not enough hardware
> behind bordeaux.guix.gnu.org currently to keep up with both the large
> number of builds on the master branch as well as building staging
> quickly.
>
> 1: 
> http://data.qa.guix.gnu.org/repository/2/branch/staging/latest-processed-revision/package-substitute-availability
>
> I know that's not what you're asking for here, but I think a big problem
> when it comes to merging branches is that of checking what's broken, and
> that's what I'd like to make easier.

Yes, definitely!

> Is there a reason why ‘make assert-binaries-available’ is just checking
> ci.guix.gnu.org?

It’s mostly that ‘guix weather --display-missing’ is not really helpful
when passed more than one URL: it reports all the things that are
missing on at least one of the URLs (this is what the comment in
‘Makefile.am’ suggests).

The goal of this command is to check that “basic packages” build and are
available, and we can expect basic packages to be available on both
build farms so I think it’s OK to check just one of them.  (When I first
wrote that manifest, I naively thought we’d be at 100% at any time since
this is really the baseline…)

> i586-gnu is a shared problem though, I'll try and see if I can get some
> childhurd VMs working, although I'm not sure this'll be timely enough
> for the upcoming release.

For i586-gnu the expectation is really low right now: see
‘%base-packages/hurd’ in ‘etc/release-manifest.scm’.

Ludo’.

Re: Planning for a release, for real

[Maxime Devos]

On 07-10-2022 11:50, Ludovic Courtès wrote:

Hi,

Maxime Devos  skribis:


I have some unapplied security patches (from before the latest release
(1.3.0) (!)) (more precisely, some patches that prepare for actually
being able to write the security patches, once the preparation patches
are merged, the actual security fixes should be relatively simple); I
think it would be rather bad for known security fixes to not be
applied for a whole release, especially given how long release cycles
are in Guix.


Could you provide links to these?


'These' are the ‘openat’ patches:


If they depend on ‘openat’ in Guile, that won’t be an option
unfortunately since we’re not going to upgrade the ‘guile’ package
during that time frame.


However, upgrading the Guile package is not required, I proposed making 
a separate ‘guile-with-openat’ package (= current Guile + some patches), 
which can then be used by the service code: 
 (without world rebuilds).


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Planning for a release, for real

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> I have some unapplied security patches (from before the latest release
> (1.3.0) (!)) (more precisely, some patches that prepare for actually
> being able to write the security patches, once the preparation patches
> are merged, the actual security fixes should be relatively simple); I
> think it would be rather bad for known security fixes to not be
> applied for a whole release, especially given how long release cycles
> are in Guix.

Could you provide links to these?

If they depend on ‘openat’ in Guile, that won’t be an option
unfortunately since we’re not going to upgrade the ‘guile’ package
during that time frame.

Thanks,
Ludo’.

Re: Planning for a release, for real

[Ludovic Courtès]

Hi,

Julien Lepiller  skribis:

> I'll take care of the cranslations (notifying translators, ensuring string 
> freeze is respected, …)

Great, thanks.

> We need to be careful not to start the stsing freeze step too early. Last 
> time (or previous?) we started a week before the scheduled release date, but 
> the schedule slipped by a few weeks and we had some pressure in the pipeline 
> because some patches could not be applied because of string changes.
>
> Let's try to have a better vision on the planning this time :)

Right!  How long do you think we need for the string freeze?

I feel that thanks to Weblate translations are continuously updated, so
maybe things can be frozen for a shorter period of time?

Thanks,
Ludo’.

Re: Planning for a release, for real

[Christopher Baines]

Ludovic Courtès  writes:

> We need to plan and coordinate.  Releases have to be a group effort;
> some of the most important work won’t be coding but coordination.
> Coordination is key.  I don’t think I should be spearheading that
> effort, but I’m happy to be part of it.
>
> Who’s ready to commit time towards that goal for the coming weeks?
>
> Here’s a list of things to do to get there:
>
>   • Merge ‘staging’ (?).  What’s the status of that one, it seemed ready
> a couple of weeks ago, but then I lost track of it.  Marius?
>
> We need a ‘staging’ champion to keep track of what’s left to be
> done, reports progress, pings people, etc.  That person does not
> have to be hacking like crazy, on the contrary!

I'd like to get qa.guix.gnu.org to the point where it's useful for
getting branches merged. Currently, it's possible to submit builds for
branches, which is happening currently for staging.

While that's great, the substitute availability for the branch is still
poor [1], the builds are happening, but there's just not enough hardware
behind bordeaux.guix.gnu.org currently to keep up with both the large
number of builds on the master branch as well as building staging
quickly.

1: 
http://data.qa.guix.gnu.org/repository/2/branch/staging/latest-processed-revision/package-substitute-availability

I know that's not what you're asking for here, but I think a big problem
when it comes to merging branches is that of checking what's broken, and
that's what I'd like to make easier.

>   • Get base binaries on all supported architectures in a timely
> fashion, or drop some of the architectures.
>
> Namely, ‘make assert-binaries-available’ is currently failing.  It
> uses a manifest that encodes what we consider to be the basic
> requirements for each architecture; it’s not demanding for
> aarch64-linux, even less for armhf-linux and i586-gnu—yet we’re not
> meeting these criteria yet.
>
> We need to look at missing substitutes, address build issues and
> build farm issues that cause them until we get to zero failures.  If
> after some effort we fail to get to zero, then we should consider
> dropping architectures (I’m looking at armhf-linux and i586-gnu
> specifically).
>
> Again we need a champion to keep track of this and ping people so we
> make progress!

Is there a reason why ‘make assert-binaries-available’ is just checking
ci.guix.gnu.org? One of the main reasons why bordeaux.guix.gnu.org
exists is to address the lack of substitutes, and if you do check the
mainifest against bordeaux.guix.gnu.org you do get a slightly higher
percentage.

i586-gnu is a shared problem though, I'll try and see if I can get some
childhurd VMs working, although I'm not sure this'll be timely enough
for the upcoming release.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Planning for a release, for real

[Maxime Devos]

On 06-10-2022 16:50, Ludovic Courtès wrote:

Hello Guix!

Will Guix’s 10th year be a release year?  I hope so!

We need to plan and coordinate.  Releases have to be a group effort;
some of the most important work won’t be coding but coordination.
Coordination is key.  I don’t think I should be spearheading that
effort, but I’m happy to be part of it.

Who’s ready to commit time towards that goal for the coming weeks?

Here’s a list of things to do to get there: [...]


I have some unapplied security patches (from before the latest release 
(1.3.0) (!)) (more precisely, some patches that prepare for actually 
being able to write the security patches, once the preparation patches 
are merged, the actual security fixes should be relatively simple); I 
think it would be rather bad for known security fixes to not be applied 
for a whole release, especially given how long release cycles are in Guix.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Planning for a release, for real

[Julien Lepiller]

I'll take care of the cranslations (notifying translators, ensuring string 
freeze is respected, …)

We need to be careful not to start the stsing freeze step too early. Last time 
(or previous?) we started a week before the scheduled release date, but the 
schedule slipped by a few weeks and we had some pressure in the pipeline 
because some patches could not be applied because of string changes.

Let's try to have a better vision on the planning this time :)

Le 6 octobre 2022 16:50:22 GMT+02:00, "Ludovic Courtès"  a écrit :
>Hello Guix!
>
>Will Guix’s 10th year be a release year?  I hope so!
>
>We need to plan and coordinate.  Releases have to be a group effort;
>some of the most important work won’t be coding but coordination.
>Coordination is key.  I don’t think I should be spearheading that
>effort, but I’m happy to be part of it.
>
>Who’s ready to commit time towards that goal for the coming weeks?
>
>Here’s a list of things to do to get there:
>
>  • Merge ‘staging’ (?).  What’s the status of that one, it seemed ready
>a couple of weeks ago, but then I lost track of it.  Marius?
>
>We need a ‘staging’ champion to keep track of what’s left to be
>done, reports progress, pings people, etc.  That person does not
>have to be hacking like crazy, on the contrary!
>
>  • Get base binaries on all supported architectures in a timely
>fashion, or drop some of the architectures.
>
>Namely, ‘make assert-binaries-available’ is currently failing.  It
>uses a manifest that encodes what we consider to be the basic
>requirements for each architecture; it’s not demanding for
>aarch64-linux, even less for armhf-linux and i586-gnu—yet we’re not
>meeting these criteria yet.
>
>We need to look at missing substitutes, address build issues and
>build farm issues that cause them until we get to zero failures.  If
>after some effort we fail to get to zero, then we should consider
>dropping architectures (I’m looking at armhf-linux and i586-gnu
>specifically).
>
>Again we need a champion to keep track of this and ping people so we
>make progress!
>
>  • Address the blockers of , most of
>which are issues in the installer.
>
>  • Freeze strings: enter a period where translatable strings in the
>code and in the manual must not be changed so translators have a
>chance to keep up.  Julien, how would you like to do that?  Weblate
>has given us more flexibility it seems.
>
>  • Publish a release candidate and call for testing of the installer in
>particular.  Fix bugs, loop.
>
>  • Update NEWS (mostly done already!), prepare a blog post listing the
>highlights and linking to the relevant material.  (See
> for inspiration.)
>
>I’d like us to do this with an eye of getting better organized, which
>involves defining roles such as that of “release managers”.
>
>The NixOS folks handle this in a way that I find inspiring, with
>rotating release manager responsibilities, a schedule announced upfront,
>and a detailed description of the process:
>
>  https://github.com/NixOS/nixpkgs/issues/193585
>  https://nixos.github.io/release-wiki/Home.html
>
>We have
>
>but it’s low-level and dates back to a time where release were a
>one-person activity.  Time for a change.
>
>So, who’s in?  Let’s get our act together!
>
>Ludo’.

Planning for a release, for real

[Ludovic Courtès]

Hello Guix!

Will Guix’s 10th year be a release year?  I hope so!

We need to plan and coordinate.  Releases have to be a group effort;
some of the most important work won’t be coding but coordination.
Coordination is key.  I don’t think I should be spearheading that
effort, but I’m happy to be part of it.

Who’s ready to commit time towards that goal for the coming weeks?

Here’s a list of things to do to get there:

  • Merge ‘staging’ (?).  What’s the status of that one, it seemed ready
a couple of weeks ago, but then I lost track of it.  Marius?

We need a ‘staging’ champion to keep track of what’s left to be
done, reports progress, pings people, etc.  That person does not
have to be hacking like crazy, on the contrary!

  • Get base binaries on all supported architectures in a timely
fashion, or drop some of the architectures.

Namely, ‘make assert-binaries-available’ is currently failing.  It
uses a manifest that encodes what we consider to be the basic
requirements for each architecture; it’s not demanding for
aarch64-linux, even less for armhf-linux and i586-gnu—yet we’re not
meeting these criteria yet.

We need to look at missing substitutes, address build issues and
build farm issues that cause them until we get to zero failures.  If
after some effort we fail to get to zero, then we should consider
dropping architectures (I’m looking at armhf-linux and i586-gnu
specifically).

Again we need a champion to keep track of this and ping people so we
make progress!

  • Address the blockers of , most of
which are issues in the installer.

  • Freeze strings: enter a period where translatable strings in the
code and in the manual must not be changed so translators have a
chance to keep up.  Julien, how would you like to do that?  Weblate
has given us more flexibility it seems.

  • Publish a release candidate and call for testing of the installer in
particular.  Fix bugs, loop.

  • Update NEWS (mostly done already!), prepare a blog post listing the
highlights and linking to the relevant material.  (See
 for inspiration.)

I’d like us to do this with an eye of getting better organized, which
involves defining roles such as that of “release managers”.

The NixOS folks handle this in a way that I find inspiring, with
rotating release manager responsibilities, a schedule announced upfront,
and a detailed description of the process:

  https://github.com/NixOS/nixpkgs/issues/193585
  https://nixos.github.io/release-wiki/Home.html

We have

but it’s low-level and dates back to a time where release were a
one-person activity.  Time for a change.

So, who’s in?  Let’s get our act together!

Ludo’.


signature.asc
Description: PGP signature