On Fri, May 9, 2025 at 5:55 PM Steve George <st...@futurile.net> wrote:
>
> I hope the initial user experience wouldn't be to "break on the user's first
> pull", since with annual releases we wouldn't have release artefacts that are
> 2.5 years out of date. And, we'd also degraft regularly which would be
> beneficial for all users.
>
> As you can tell I would _love_ us to be able to have a slower moving branch,
> but purposefully have kept the GCD more limited. For now focusing on the step
> forward of regular releases.
I have not updated a 2.5+ year old Guix system, but what is the issue
here? How is this any different from updating a week old system? If
the archive contains broken packages then the user upgrade experience
will fail just the same. And clearing the archive of broken packages
also breaks user manifests!
> > 2) The project is currently unable to keep up with the teams workflow,
> > and now we are introducing an additional, quite long pause into the
> > calendar.
> I agree this is a problem, for the purposes of focusing discussion on this
> GCD let's keep it out of the remit. Perhaps a separate discussion or separate
> GCD!
Performance of the teams workflow is integral to this proposal. We can
barely get a handful of teams processed in a month, and now we propose
allowing all teams a go within a four week window. And it seems to me
the biggest issue with the teams workflow is the indeterminate nature
of moving to the head of the queue. This proposal synchronizes many
activities to an annual process for which the volunteer developers may
likewise not be available.
### 2. Notify teams of upcoming release
Make sure all teams are aware of the upcoming release. This gives
them 4 weeks
to undertake any large transitions or major changes.
> > 3) Package cleanup is a problem that I believe we are afraid to
> > address. I agree that we should not have package "ownership", but
> > perhaps "sponsorship" or (to borrow from this GCD) "advocate" with
> > notifications when builds break on CI. I believe this proposal is too
> > aggressive in pruning packages without considering alternatives (in
> > another GCD).
>
> Can you point me to the part where you think it's too aggressive? Maybe it's
> overstating it in some way. In my mind I think the release is a checkpoint
> where we can use the package sets and the project plan focus to do what we
> should be doing using our existing process.
The removal of any broken package:
Packages or services that do not build for the Primary
architectures as part of a release
would be removed from the archive using Guix's deprecation policy.
> > I think we should greatly reduce the scope and initially try (as I
> > noted in December buried in the "On the quest for a new release model"
> > discussion) creating a release team which would:
> > 1) operate as any other team
> > 2) be responsible only for building and improving release artifacts
> > 3) operate with a cadence sufficient to build and retain this
> > expertise (which would currently be one cycle of the queue, but
> > ideally every ~3-4 months)
> >
> > By using the teams queue everyone will know when the release is
> > coming, and whether their branch will be merged before or after the
> > next release.
>
> In a way this does create a team in the way you brought up in December [0].
> It creates a "release team" for one project and tries to limit the "toil" by
> keeping the project to 3-4 months of effort. It defines a specific time when
> a release will happen so everyone knows when it's happening, can get involved
> and help.
>
> Where it differs is that realistically the release artifacts involve the
> kernel, core packages, networking, base utils, guix daemon, and graphical
> environments [1]. I don't think this can be done by 3-4 volunteers, there has
> to be some co-ordination and energy from all teams - we are a small team
> after all!
Yes, those teams are involved if packages or the release scripts are
broken? I'm with Ekaitz on this one, the process to build the release
artifacts should be automated. We already do this for the binary,
which is why I have not had to install a 2.5+ year old system :)
I see Andreas' response that we need a big release hullabaloo to rally
around since tidying up and testing the release is "probably not much
fun". But this process simply codifies the pre-teams workflow that did
not work. And while I certainly welcome this discussion, I don't see
this as a whole qualifying as a GCD (from 001: "A change may be deemed
*significant* when it could only be reverted at a high cost or, for
technical changes, when it has the potential to disrupt user scripts
and programs or user workflows").
This proposal simply takes the processes which are performing poorly
and stuffs them into a very manual annual release process. Ungrafting
can and should be coordinated on feature branches. We need better
methods to identify, track, and notify users of their broken packages.
The teams workflow needs to be clarified (QA vs CI) and coordinated
(thanks, Andreas!) and possibly preemptive.
We tested codeberg before the GCD to switch over. We should likewise
test this release schedule before codifying in a GCD.
Greg
