Hi Maxim, >> Note also that we were “only” 3 weeks late thanks to the hard work of >> zimoun and Leo early on keeping track of everything that needed to be >> addressed. If someone wants to propose a date for the next release and >> take responsibility as “release keeper”, we’ll all welcome that! > > Yes, thank you Simon and Leo for the help with the release! I felt less > lonely :-). I've learned that producing a release can easily take 2-3 > weeks even in good conditions (e.g., not many blockers to fix). I'd > suggest anyone (myself included :-)) trying to meet the schedule to > seriously start trying to put out RCs a month before the planned release > date.
Thank you! And thanks to all the people involved. :-) For what it is worth, the anniversary dates seems good targets as release dates: - April, 18th (init commit) - November, 23rd (first announce) Do you plan to keep a Release Bug open with all the blocking bugs? Does it help? If yes, does it make sense to start now to add some or only ~2 months before the target? > Perhaps we can aim for the next release mid-September (core-updates). > I'm not too sure of the status of core-updates right now, but last time > I worked on it was in a rather good state. I remember a plot sent to guix-maintaainers about the number of grafts, the core-updates merges and the release dates. I am not sure it is really interesting and it is worth to resend it, or maybe dumping the Cuirass database to investigate a bit more. Well, my point is the core-updates merges and the release dates should be synchronized; say target the core-updates for end of September, then the release for November. To me, this synchronisation makes senses because it constraints the ~6months core-updates cycle and in the same time, the 2 releases per year. Cheers, simon
