Hi Steve,
Thanks for this proposal!
Well, I’ve not commented yet because I’m very doubtful that releasing
more often can be solved with a GCD. I mean, yeah we all would like
more releases, and then? :-) Look, on February, we were all in the
same room and we all agreed that we had to work on releasing soon and
we cooked a plan to make it happen. But the release has not come yet…
Do not take me wrong. I do not want to be the pessimistic one cutting
the positive circle trying to move forward. As I wrote many times over
the years, yeah for sure, releasing more often would be more than great!
Somehow, I think that “regular and efficient release“ is a good target
but considering the current situation, I’m doubtful we will be able to
go in only one go – just by deciding from the top and writing down a
planning.
Instead, I think we need two intermediary steps:
(1) Clarify what means being a member of a team.
(2) Clarify the branching model; especially how to deal with grafts.
To me, they are requirements before being able to have regular releases.
Therefore, I read this GCD as setting the goal in order to address the
well known blockers as (1+2) and, only after, we will be able to have
regular releases without burning out.
Moreover, I think it’s difficult to find the right balance between
volunteering work and commitments. Today, make a release is a piece of
work. For sure, it’s possible to smooth the things and automatize with
various helpers etc. but if it’s not done yet, maybe it’s because it’s
not trivial or maybe even more work than the ‘piece of work’ itself. :-)
Yes, I’m convinced that committing to have “regular releases” will
improve all the releasing process over the next releases. For sure!
And it’s probably by making such commitment that the releasing process
will be improved. But we are not there yet, IMHO, so it’s still a piece
of work and it’ll still remain one for some release cycles.
Therefore, the core of this proposal appears to me what is the bar?
Until now, the bar was high. Maybe, one way to release more often is to
decrease the bar so it’s easier to pass it and then we can rise it up,
by incremental improvements. This is the section about Package Sets,
Tiers and Release Artifacts.
To me, that’s the key.
And concretely, who is ready to commit for 12 weeks (maybe 2 times) as
Release Manager?
All that said, some comments hoping it might improve the bootstrap of
“regular releases”. :-)
> ## Package Sets
[...]
> The package sets would be:
>
> * minimal: packages required to boot and install a minimal Guix or Guix System
> install. This would include the guix daemon, kernels, boot loaders,
> file-systems and minimal utilities.
> * standard: packages that create a core installation for all other uses.
> * desktop: provides the packages necessary for a desktop. This would include
> things like X11/Wayland, desktop environments, key applications and themes.
> * server: provides packages and services for a server. This would include
> standard server packages and services.
> * hosted: provides packages and services which are necessary in hosted usage.
>
> Guix would still make all packages and services part of a release (the entire
> archive), but only those in the `package sets` could block a release due to a
> significant bug. The goal would be for this to be as small a set of packages
> as reasonably possible. It would mean that developers could focus on the
> critical packages and services during a release. As an example, this would
> mean that a major issue in the Linux kernel could block a release, but not an
> issue in a game.
I understand the meaning however it’s unclear to me. Instead, I propose
that the Release Team defines when they start their cycle which packages
the release will support.
Somehow, each package set should be defined by a manifest file. Here
you picked 5 use-cases, so the Release Team lists the packages in the
manifests minimal.scm, standard.scm, desktop.scm, server.scm and
hosted.scm. These manifests are considered as blockers.
If one package from one manifest fails and it’s hard to fix, then it can
be excluded; i.e., moved from Tier to another Tier.
It also would help in monitoring the CI outside the release period.
> ## Platforms and Architecture tiers
[...]
> - Primary architectures:
> - Architectures: x86_64, AArch64
> - Kernel: Linux
> - Coverage: all packages and services that are not explicitly platform
> specific must work to be included in the archive.
> - Package status: package updates should build for this architecture. If a
> package update is broken it must not be pushed to users (e.g. master).
> - Security: all packages that are maintained upstream receive updates
This does not read as the rolling release, does it? :-)
I propose:
- Tier 1:
- Architectures: x86_64, AArch64
- Kernel: Linux
- Coverage: defined by package sets.
- Tier 2:
- Architectures: all others
- Kernel: Linux
- Coverage: defined by package sets.
- Tier 3:
- Architectures: all
- Kernel: Linux, Hurd
- Coverage: all packages
For a release, Tier 1 must be all green; Tier 2 should be green; Tier 3
as good as possible.
Obviously, we can add more Tier than only 3. The main idea here is to
define what is Tier (= list of architectures, kernel, package coverage)
and what expects when this Tier in a release.
Well, maybe we could add a “service coverage”.
> ## Release team and project
[...]
> The final release team is:
>
> - a new Release Manager
> - a returning Release Manager
> - up to 4 other members, one of whom acts as the Release Advocate
Hum, 2 times 12 weeks of commitment? That’s something! :-)
For sure, back up the Release Manager with 2 people is a very good idea;
especially about knowledge transfer. Cool!
If the primary Release Manager is not able to keep the commitment (busy
by life, away from keyboard, unexpected event, etc.), then the secondary
Release Manager takes the floor. Right? But then, this “absent”
primary Release Manager, does they become the next secondary Release
Manager?
Moreover, what does it happen if the both Release Manager are not
responding? Do we delay the time to find two new Release Managers? Or
is it two of the other members?
The other question: what does it happen if the Release Team is not able
to fix a blocker? Do we delay until the fix? Do we drop the blocker?
Who decides? What is the process for making such decision?
> # Cost of Reverting
>
> If regular releases were not successful then the project would switch back to
> irregular releases. There would be no impact for exiting users as they will
> be tracking the rolling release's master branch.
>
> If the project is able to successfully undertake regular releases then over
> time it may be possible to undertake full releases every six months or some
> other release cadence.
Well, I do not have the answer and my honest question is: Is it more
detrimental to have irregular^W no release since years! than to
communicate on regular releases and fail?
> # Appendix 1: Release Project Time-line
[...]
> ### 1. Nominate a release team
> Nominate a release team with two Release Managers (1 is the previous RM), and
> up to 4 other people who will work on the release. Put out a call for a
> Release
> Advocate who can be anyone in the Guix community who's willing.
Who nominates? How?
Who decides if 7 people volunteer to be the next release team? Hum, it
will not happen, but still. :-)
The converse, what does it happen if no one volunteer? IIUC, the
primary Release Manager becomes the next secondary Release Manager, so
what does it happen if there is no one who volunteers to be the next
primary volunteer?
What does it happen if after the release, the primary Release Manager
steps down and do not become the next secondary Release Manager?
> ### 9. Ungraft master branch
> Guix master is ungrafted to minimise the difference with users of the release
> initial 'guix pull' experience.
This will take more than one week, I guess. :-) For sure, more than few
hours in the week.
I think this needs to be done by each team all over the changes
independently of the release process. As said above, I think we should
clarify what a team does. For instance, if a team introduces a graft,
then this very same team must open a branch that ungrafts and then merge
this branch as soon as possible; independently of the release.
Somehow, we removed core-updates but we have never defined a clear
strategy for ungrafting. Well, that’s outside the scope of this GCD
but, IMHO, the success of this GCD depends on how to deal with grafts.
All in all, let me know if you need a wording proposal from me about
some of my comments.
Cheers,
simon
