Re: On the quest for a new release model

[Maxim Cournoyer]

Hi,

Efraim Flashner <efraim@flashner.co.il> writes:

> On Sun, Dec 15, 2024 at 03:21:44PM -0500, Suhail Singh wrote:
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>> > Efraim Flashner <efraim@flashner.co.il> writes:
>> >
>> >> Since, IMO, the major uses of the actual guix package is for the daemon
>> >> and the installer, I think we could tag a minor release just about every
>> >> time we bump the guix package.
>>
>> That's a sensible approach.  How should the discussion proceed further?
>> Do we have a proxy to determine whether everyone who needs to be
>> involved for consensus-based decision-making has weighed in?
>
> I'd argue that cutting releases is one of those specifically maintainer
> duties but I'd love to hear from other people who disagree.

I'd tend to agree.  A maintainer who doesn't cut releases or organize to
make them happen is a poor maintainer (hello!).

> If we do consider the daemon and installer the main reason to actually
> cut a release, then I'd argue the daemon always works (we'd know
> otherwise), I think we have an installer team, and we should probably
> get some feedback from the desktop teams to make sure everything seems
> to be working well enough.
>
> I have some opinions about our aarch64 based images, but that should be
> a separate email.

I think one reason I'm so turned off from attempting to produce a
release is mainly the very high standard that Ludovic has set for
releases (hats off!), which is quite a lot of tedious work:

1. Comb thousands of commits (and since it'd been 2 years, more like
tens of thousands of them) to find news worthy items to put in the
NEWS.org file (which goes in the eventual announcement email)

2. Write a new blog post for the release, with the above information,
and often more detailed explanation on new features.

3. The challenging/labor intensive integration work such of attempting
to fix all system tests which often bitrot due to not so many people
(myself included) routinely running them and noticing (it's so costly to
do so, I can't really fault them), though I/we should register to the CI
notifications for the 'tests' job, that'd help keeping track of new
failures.

4. Some arcane Perl tool that needs to patch is used to produce the
final release email/upload artifacts, IIRC.  We should have better tools
than that.

5. I remember it to be very time consuming to try to just produce the
release artifacts for all platforms, building the current Guix then the
nested Guix for all targeted architectures.  If it fails, you're in for
a new lengthy round as the process must be started over ('make
release').

6. And of course, since a Guix release is mostly useful for people
installing it on foreign distributions or as fresh Guix System
installations, testing this is important, but also labor intensive
manual work.

If we can agree that producing a release with lowered expectations is
better than producing none, I don't mind to get the ball going.  I'd
drop the combing of thousands of commits for one thing, focusing just on
what's in our etc/news.scm file, or what is on the top of my head.  The
blog post may be spartan, with little backstory or examples.  The email
announcement email may not match the GNU release format, until we get to
rewrite the tool to match our multi-artifacts requirements (in Scheme,
of course).  Testing may have been mostly left to testers out there that
have foreign systems or VMs to experiment with, or the time to install
Guix from scratch using the installer.  A best effort would be done to
fix as many tests before releasing, without the promise of fixing them
all.

Parties interested in refining the release process can have a look at
the 'release' target of our Makefile.am file at the root of the Guix
repo, or at the doc/release.org file in the guix-maintenance repo.

Long term I think I'd like to see for releases:

1. Simplicity - just a tag, release email, artififact uploads may be
good enough, if we release often.

2. Automation - We already have many things automated, but it could be
polished a bit more (such as a better tool to produce the announcement
email), and perhaps some way to automatically test that a Guix istalled
via guix-install.sh' in various environments work (perhaps Docker could
help with that, having readily minimal images of Debian, Ubuntu, Fedora,
etc. to run our script on).

3. Frequency - we want to release often

-- 
Thanks,
Maxim