On Sun, Jan 25, 2026 at 06:38:04PM +0100, Rutherther wrote: (...) > Ludovic Courtès <[email protected]> writes: (...) > > I’m joining others in congratulating the release team, Rutherther, > > Rodion, Efraim, and Noé, as well to everyone who helped one way or > > another on the way, with a special mention to Luis for the artwork. > > You people rock!!
Yeah agreed - thanks for stepping up everyone, it's fantastic to have a release! (...) > > Big up to Steve (Futurile) as well: I was a fan of GCD 005 but it wasn’t > > entirely clear to me that this document would be performative as it > > turned out to be. :-) Well done! > > Personally I would wait for a few more releases before deciding how > performative it is, but I agree even if it ended at one release, it's > still good news. Agreed. There was a big push during the consideration of the GCD for automation. When the retrospective happens I think that should be a key question - are there parts we can automate, any step forward is better than none I guess? My personal feeling is that some of my "big Linux" (hah hah) experience might make the release process too heavy for a volunteer group. So maybe another part of the retrospective can be whether there are particular steps that should be dropped / lightened or reconfigured in some way. > > > > If I read it correctly, our next release is for July. Who’s up for that > > one? (...) Whatever the date I would like to help more on the next one for sure! > Tbh I am not sure if it makes sense to make a release so soon. It was > expected the first release would be in November and then in July. Maybe > the next release can thus be moved a bit and only with the next year we > could get to the July schedule. > > Since the release schedule is planned for 4 months, I think that means > the preparations would begin in March? That feels very soon. I think one > good thing for the release would be if there has been core-packages > cycle completed (on the other hand, it doesn't have to be a blocker). Is > it even realistic that core-packages cycle is going to make it till > the time before freezes would occur? > > In case it was ready after the freezes, that would mean further delays on > such an important world rebuild. (...) I really think we have to sort out the build-farm so these sorts of things are NOT in conflict. Now that you guys have experiene on the branching strategy for release, maybe there's some ways to do things in parallel. > (I think I could be in the next release team, but definitely not if it > starts in March, that's just too soon for me after this one :) I am > still planning to work on some of the found issues, though) (...) Summer is tough for us as most people are away, but what about pushing back by the same amount of time. So rather than July we go to October or if we can compress September. > > > > What are the main takeaways of this effort and things that the current > > release team would suggest addressing by the next release? > > We will have meeting on 7th of Feb to do release retrospective, where we > could talk about these. For now I have been aggregating the issues found > for this release that should ideally be solved, here - > codeberg.org/guix/guix/milestone/46937. > > On the meeting, I expect we can talk about these points: > - Better documentation of the release process, from what we learned from > this release > - Freezes > - What is their point and thus how to know when to remove a freeze > - How to better 'enforce' them (Andreas had some good points about > a push hook that could tell you there is a freeze) > - Should there be anything changed in the communications of the release > - When does it make sense to have the next release and should the > current team somehow try to take care of finding the next release team (...) Sounds great. Steve / Futurile
