Subject: Re: [bug#78332] GCD005: Regular and efficient releases (submitted)

From: "Philip McGrath" <[email-masked]>
Date: Sat, 21 Jun 2025 11:50:05 -0400

On Fri, Jun 20, 2025, at 1:53 PM, Andreas Enge wrote:
> Am Fri, Jun 20, 2025 at 11:28:19AM -0400 schrieb Greg Hogan:
>> """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.
>

I read the second paragraph quoted from GCD 005 as a non-exhaustive list of factors that "may" make a change "significant", not as a definition restricting the meaning of "significant" to only the examples it describes.

The first paragraph says that "whether a proposed change is significant" is to be "determine[d]" by "the GCD process". To me, it seems fairly clear that the release model for Guix "require[s] attention from the community at large", so it seems fruitful to use "a documented way to bring about broad community discussion and to collectively decide on the proposal".

Maybe a difference from some other GCDs is the consequences if this does not achieve consensus. The current policy is basically "releases happen when someone feels like it's time and puts in the work to make one". I don't think there's anything in current policy that *forbids* interested volunteers from making annual releases along the lines of this proposal, even if GCD 005 does not achieve consensus. But hopefully we *can* achieve consensus on what Guix's release model should be, and, if so, it will be valuable to document that consensus.

Philip