Hi Reza, On 10 May, reza wrote: > Hi Steve > > Thanks for the effort you put into this, I just wanted to add my > thoughts when reading it... (...)
Appreciate you reading it and taking the time to send your thoughts! (...) > > ### 4. Toolchain and transition freeze > > No major changes to toolchains (e.g. gcc-toolchain, rust-1.xx) or runtimes > > (e.g. java). There should be no changes that will cause major transitions. > > > > Debian defines a transition as one where a change in one package causes > > changes > > in another, the most common being a library. This isn't suitable for Guix > > since > > any change in an input causes a change in another package. Nonetheless, any > > change that alters a significant number of packages should be carefully > > considered and updates that cause other packages to break should be > > rejected. > > > > No alterations to the Guix daemon or modules are accepted after this point. > > Packages and services in the 'minimal' package set should not be > > altered. > > Should this not be done on a separate release branch as soon as we start > with the release? There seems to be no need to freeze master as soon as > we branch off a release branch. Or did I understand something wrong? (...) It definitely _can_ be done that way, it wouldn't be my preference. In my experience, if we want the whole group to focus on doing a great release then branching off as late as possible is the best option. The social signal is that "we're all focusing on creating a release now". As we know people have different motivations and priorities, if everyone isn't focused on the release, then there's a tendancy for people to keep hacking (introducing lots of changes etc) and that can make creating a release very difficult as new instability is brought into the archive. We kind of had a version of this a few months ago when Ludo asked for volunteers to work on doing a release >From a technical perspective, the later that we branch off from master the >better since that limits the divergence between what's in the release and what >package versions the user gets when they do a 'guix pull'. It's also, I think, >quite difficult managing multiple branches, so I would limit the over-head as >much as possible. That all said, it's definitely possible to branch earlier and then do everything that way. In a way that's the "Debian" approach of having a "testing" branch and then moving it towards a release. So if the group wanted to try that approach ... (...) > I am missing the automation aspect a little in this GCD. As I understand > the release take so long because there is a lot of manual effort > involved in doing one. I think it is worthwhile to also work towards > more automation in preparing a release and testing it. I have by no > means a lot of insight into doing a release but my impression is that > automation could drastically improve the time to relase. (...) The main piece of automation that limits our ability to do a release is to do with the architectures and `make dist`. See this thread from February: https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00184.html The commercial distro's do have a lot of release automation that goes beyond the common tools (e.g. CA/QA/Bugtracker). At least when I was involved we had a lot of automation for automating package updates, complex hardware testing, installation testing, and various forms of upgrade testing. This short section from OpenSUSE's 'Factory development model' might give you some ideas: https://en.opensuse.org/openSUSE:Factory_development_model#Development_Process_Overview But, please note that the the core work of creating a release - packaging, testing packages install/work, integration between packages (services in Guix), testing the release and solving bugs - is mostly developer effort (even for RedHat or Canonical). I personally, think we should focus on the foundations of our developer experience first and automate in that area. Things like QA, visibility into package build/regressions, automated updates of packages. We have some of these things, and the Codeberg migration may help us improve in other areas. Here's a great example from Gentoo (similar type of volunteer distribution to Guix) of tying everything together in a clear way: https://packages.gentoo.org/packages/mail-client/neomutt It's true then that this GCD does not suggest any automation. It's trying to move forward through organisational (project plan) and some technical (reducing work through package sets/supported architectures). I would love to see the project improve developer tooling - it's important - but not specific to releases. For example, I would love to see automated update testing [0] where some of the base work has already been done. Do you have any particular areas where you think "automation" would improve releases? And/or (outside of the GCD) do you see the value of improving our developer tooling? Steve / Futurile [0 https://lists.gnu.org/archive/html/guix-devel/2024-12/msg00011.html
