unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* 1.5.0 release?
@ 2024-09-04 18:51 Greg Hogan
  2024-09-06  9:32 ` Ludovic Courtès
  0 siblings, 1 reply; 4+ messages in thread
From: Greg Hogan @ 2024-09-04 18:51 UTC (permalink / raw)
  To: guix-devel

Hi Guix,

With the recent core-updates merge, and as the master branch
stabilizes, is there a plan or desire for a 1.5.0 release?

It has been 20 months since the 1.4.0 release, which is already more
than the previously longest interval (18 months for v1.4.0). 2023 was
the first year without a release since the project was started.

This seems to be the ideal time to create new installation artifacts
(shortly after base packages have been updated) so as to reduce the
number and size of packages to be replaced post-installation.

Greg


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

* Re: 1.5.0 release?
  2024-09-04 18:51 1.5.0 release? Greg Hogan
@ 2024-09-06  9:32 ` Ludovic Courtès
  2024-09-10 22:21   ` Greg Hogan
  0 siblings, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2024-09-06  9:32 UTC (permalink / raw)
  To: Greg Hogan; +Cc: guix-devel

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> With the recent core-updates merge, and as the master branch
> stabilizes, is there a plan or desire for a 1.5.0 release?

Desire, definitely; plan? we have to come up with one.

I think there should be a team of ~4 volunteers who can commit to focus
on it for, say, 2–5 months¹ (the shorter the better, but we have to
prepare for extra time).

Since I was involved in previous releases, I would be happy to help and
mentor when needed (as an outsider), but I think leadership and
coordination of this effort should come from other community members.

An important skill required here is the ability to keep track of what
needs to be done, what is outside of that scope, coordinating the work
of individuals, and regularly communicating progress with the broader
community.  Regular communication is what will allow people to help in
areas they’re familiar with.

I know there are people who’d do a great job on that coordination part
and people who’d be great on the more technical side of things.

Thoughts? Volunteers?

Ludo’.

¹ This has been discussed several times over the past few years.  NixOS
  has had dedicated release teams for a while: each team is a small
  group of people that focuses on one release for a few months, and then
  passes on the torch to another group.  Rotation is important.


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

* Re: 1.5.0 release?
  2024-09-06  9:32 ` Ludovic Courtès
@ 2024-09-10 22:21   ` Greg Hogan
  2024-09-11 14:44     ` Giacomo
  0 siblings, 1 reply; 4+ messages in thread
From: Greg Hogan @ 2024-09-10 22:21 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

On Fri, Sep 6, 2024 at 5:32 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hi Greg,
>
> Greg Hogan <code@greghogan.com> skribis:
>
> > With the recent core-updates merge, and as the master branch
> > stabilizes, is there a plan or desire for a 1.5.0 release?
>
> Desire, definitely; plan? we have to come up with one.
>
> I think there should be a team of ~4 volunteers who can commit to focus
> on it for, say, 2–5 months¹ (the shorter the better, but we have to
> prepare for extra time).

That seems like a lengthy time to roll some release artifacts. Is the
remaining effort to fix failing builds?

With Guix embracing the chaos of rolling releases, and a presumption
that users will `guix pull` soon after installation, I count only
three motivations to tag a new release: 1) replacing an old release
with an outdated Guix unable to self update, 2) security fixes for
installation packages so as not to be immediately pwned, and 3)
minimizing the number of replacement installation packages (especially
after core packages updates).

Whether the remainder of the packages are available or even buildable
at release seems inconsequential, since without release branches or
backported security fixes all Guix systems should be kept up-to-date.
We do need "quality control", but on a continuing basis rather than at
particular points in time.

I believe other distributions the size of Guix have some version of
package "ownership" (responsibility), which both reduces duplicated
effort and when lacking informs deprecation and removal of the
package. Guix teams is coarse, both in subsetting packages and
contributors.

Greg


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

* Re: 1.5.0 release?
  2024-09-10 22:21   ` Greg Hogan
@ 2024-09-11 14:44     ` Giacomo
  0 siblings, 0 replies; 4+ messages in thread
From: Giacomo @ 2024-09-11 14:44 UTC (permalink / raw)
  To: guix-devel, Greg Hogan, Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

Hi Greg, Ludo', 

I think 5 months are a long but not unbelieveable amount of time, especially if the team has to be onboarded in that time frame as well.

I work for my dayjob as Release Engineer at a company that makes another Linux distribution, so I happen to have an idea of some of the necessary task around releases, never did in Guix context but I'd be willing to learn anything required.

If a team is formed I would love to participate in Guix 1.5 release, for sure I don't think I can lead it but if I my work can help increase the bus factor please count me in.

Cheers,

giacomo

[-- Attachment #2: Type: text/html, Size: 684 bytes --]

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

end of thread, other threads:[~2024-09-11 15:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-04 18:51 1.5.0 release? Greg Hogan
2024-09-06  9:32 ` Ludovic Courtès
2024-09-10 22:21   ` Greg Hogan
2024-09-11 14:44     ` Giacomo

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).