Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)
I agree string freeze was way too long for this release. We entered string freeze one week before the planned release date, it got pushed by almost one month. For next release, I think it would be better to enter string freeze along with rc1 or a bit later, but always at least give one week before release (so a late string freeze could delay release by a few days). Le 16 mai 2021 12:02:38 GMT-04:00, Vagrant Cascadian a écrit : >On 2021-05-16, Maxim Cournoyer wrote: >> 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. > >It would be nice to get a Release Candidate (or Pre Release?) out with >some time before the string freeze; it's easiest for me to do the >spelling/grammar/typo checks and fixes after the first RC tarball (as >it >is basically just part of my packaging for Debian workflow), but was a >little disappointing to not be able to get such trivial fixes into the >release. > >Alternately or additionally, setting up a "make dist" job on >ci.guix.gnu.org and publishing the resulting tarball somewhere would >allow me to check at arbitrary points during the release cycle and >catch >things earlier. > > >live well, > vagrant
Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)
Hi all, On +2021-05-17 10:43:36 -0400, Leo Famulari wrote: > On Mon, May 17, 2021 at 02:55:39PM +0200, zimoun wrote: > > 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. > > I like this idea. > This sounds like planning activity. Gnome has an app called planner ;-) Would it make sense to discuss a way to put these rc- and other related goals on a gantt chart? Maybe even automate import from mailing list emails marked with e.g. [release-planning] in the subject and one delimited markup region like --8<---cut here---start->8--- planner-importable xml here --8<---cut here---end--->8--- Discussion without triggering automated import would just leave "[release-plannng]" out of the Subject: line, or have e.g. [release-discussion] in the Subject: line. Anyway, I thought a nice gantt chart .svg or .png or .pdf might be nice :) Thoughts? -- Regards, Bengt Richter
Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)
On Mon, May 17, 2021 at 02:55:39PM +0200, zimoun wrote: > 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. I like this idea.
Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)
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
Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)
On 2021-05-16, Maxim Cournoyer wrote: > 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. It would be nice to get a Release Candidate (or Pre Release?) out with some time before the string freeze; it's easiest for me to do the spelling/grammar/typo checks and fixes after the first RC tarball (as it is basically just part of my packaging for Debian workflow), but was a little disappointing to not be able to get such trivial fixes into the release. Alternately or additionally, setting up a "make dist" job on ci.guix.gnu.org and publishing the resulting tarball somewhere would allow me to check at arbitrary points during the release cycle and catch things earlier. live well, vagrant signature.asc Description: PGP signature
GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)
Hello, Ludovic Courtès writes: > Hi! > > Maxim Cournoyer skribis: > >> We are pleased to announce the release of GNU Guix 1.3.0! > > Yay, congrats everyone! > > Kudos Maxim for taking responsibility for the whole process! Now you > know what can be improved :-) and I’m interested in helping make the > process smoother. Thanks :-). It was nice to have the backing of the bug fixing squad and your generous contributions in the release material write-up. Thanks to Julien Lepiller for their help and availability w.r.t. the translations. > There’s no rush, but we can already start thinking about who’s turn is > next. It’s great if it’s you, Maxim, but if another experienced hacker > is interested, please make yourself known! I wouldn't mind to do it again; twice in a row seems like it may be a bit fresh in my mind and enable me to do more refinements to the build system. I'd also be happy to mentor someone else to try their hand at it. I feel like rotation improves our processes, especially w.r.t. to its documentation. > 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. 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. Thanks, Maxim
