On Tue, May 13, 2025 at 9:11 AM Andreas Enge <andr...@enge.fr> wrote: > > Hello Greg, > > I am having some trouble following your argumentation; in the beginning > of your different postings I got the impression that you did not see > a need for releases, since one could always do a "guix pull". But then > you end with:
Hi Andreas, 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 build artifacts plus every package in working order then I find that to be a Herculean task. There is of course tremendous value in this because on every contribution the developer must investigate whether build failures are newly caused or preexisting (or ephemeral or system dependent). I fully support this attempt, I just think we should first attempt to get every package in working order before codifying this annual process in a GCD. 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 Can we not similarly automate creation of the ISO and QCOW2 artifacts? Then, as you note, these need to be manually tested and blessed as a release. But I don't see why the ancillary packages need to be in working order to cut a new release. > For instance, when merging team branches, we somehow need to negotiate the > order; individual teams will look at their branches and try to advance them, > but sometimes it may be better to let another branch go to the front. It would be nice to make your teams coordinator position official. Considering the number of ideas for improving the teams workflow, we are probably due for a GCD. And I think that is the right process, to have the GCD deliberate the lessons learned rather than speculate beforehand. > Am Mon, May 12, 2025 at 01:11:15PM -0400 schrieb Greg Hogan: > > I think we should release more often (multiple times per year) > > So I am definitely not getting your point! With the goal of moving forward, > could you try to reformulate your ideas? Are there concrete points we could > improve in the GCD, or do you think it should simply be dropped as not > relevant to the real problem? If we missed it, what is the real problem? 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). 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"? Greg
