On Fri, Jun 20, 2025 at 1:53 PM Andreas Enge <andr...@enge.fr> wrote: > > Hello, > > Am Fri, Jun 20, 2025 at 11:28:19AM -0400 schrieb Greg Hogan: > > > I think you put it very mildly; the real problem of our current process > > > is that it apparently has turned into "no releases"... This for me is > > > the most important motivation for this GCD, we need some momentum to > > > turn around this inertia. > > The GCD process is not designed for building momentum but rather for > > agreeing on significant changes. From GCD 001: > > hm, I do not get your point. Of course it is not the *process* of > submitting this GCD that is supposed to generate momentum, but the > *result* of the GCD (in case it gets accepted) that should generate > momentum to reach releases. > > > """The GCD process is a mechanism to determine whether a proposed > > change is *significant* enough to require attention from the community > > at large and if so, to provide a documented way to bring about broad > > community discussion and to collectively decide on the proposal. > > > > 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.""" > > > > What from GCD 005 is significant by this definition? > > If I follow this definition in the second paragraph, then this GCD > proposal is not significant; it can be reverted at low to zero cost. > > On the other hand, I think that putting into place a process for releases > is a significant change; and since there are several ways of getting to > a release, it is good to have a community discussion and to collectively > decide. > > My conclusion would rather be that the definition of "significant > change" in GCD 001 is a bit too narrow. For instance, I would include > organisational change in the Guix project also as significant, even if > it could easily be reverted. > > Do you have a different suggestion to end up with more regular releases? > Or do you think that regular releases are not desirable? > > Andreas
My opinions on the project release cadence are of no greater consequence than the update frequency or inclusion of any individual package by a contributor or team. Most of this GCD can simply be merged into the project documentation, which can then be updated with a new commit rather than requiring a new GCD. By codifying an annual release process we actually restrict the number of releases! And what if the June deadline is missed? If these are mere guidelines then what are we voting on? I do think the capacity of the release team to pause contributions to the master branch, or to shunt these contributions onto a staging branch, to be of significance. There are counterarguments that a pause is not necessary, but this would make for a focused GCD and discussion. Greg
