Hi Greg, thanks for clarifying, this is indeed very helpful.
Am Tue, May 13, 2025 at 11:03:02AM -0400 schrieb Greg Hogan: > There may be some confusion in terms. The GCD states "there are > currently over 30,000 packages in the archive" and "Guix would still > make all packages and services part of a release (the entire > archive)". And when I look up the definition of archive I see > references to "historical documents" and "preservation". > (...) > If a release is simply build artifacts, then we are already automating > part of this process. I count 10 builds of the binary release across > March and April: > https://ci.guix.gnu.org/search?query=guix-binary I think the release proposal tries to reach some middle ground between these. There is supposed to be a set of "important" packages which should build (or be removed, so that the users get what the description says), the "package sets". These are not yet really defined, and doing so is given as a task for the release team (no 05, "package set finalisation"). They would block a release. The remaining close to 30000 ones will be shipped ("released") whether they build or not; it is clear we will never reach a 100% perfect distribution (and I think it is a task for the teams to more aggressively remove packages in their realm that do not work, which should not be postponed and left to the release team). I agree that the GCD is a bit ambiguous about this and in particular the removal procedure; it mentions the "deprecation policy", but this takes a month in itself, so is probably not compatible with the tight release schedule. So as a practical example, I suppose we will define a desktop environment package set; gnome will certainly be a part of it, and maybe something else (xfce? sway?), but probably neiter lxqt nor kde. Then if lxqt does not build, the release team would not care. If gnome does not build, the release team would push the gnome team to repair it. In theory gnome could be removed from the release, but I find it difficult to imagine, although it would be possible as a last resort, together with an entry in the release announcement. More likely, we will all push very hard to get gnome in. But probably renounce at a last minute transition to a newer gnome version. > Does this clarify? I see this proposal as trying to 1) manually fix 2) > all of Guix's problems in 3) a shortened time window, shrinking what > we are unable to maintain in 12 months into a few weeks (the only > thing missing is closing all issues during the release cycle). Definitely not all problems, but we hope at least some! > And maybe it works! Maybe the 10x and 100x contributors, including the > sponsors of this GCD, will happily fix everything and make this > happen. I can accept that. But why not just do that already? Are the > core developers not empowered? Too deferential? What improvements does > this GCD offer other than a process to "encourage and excite"? This is the hope, that "encourage and excite" will make the difference during a release cycle. Clearly we cannot all be excited all the time :) Andreas
