Re: Branch and release process
Am Wed, Mar 15, 2023 at 09:32:44AM -0400 schrieb Maxim Cournoyer: > I see; so it'd be useful for the integration of package changes > impacting multiple others; some kind of staging or core-updates > topic-focused branches. Simple leaf package updates could still be > merged directly to master without going through the go-team branch, > right? Exactly! Andreas
Re: Branch and release process
Hi Efraim, Efraim Flashner writes: > On Tue, Mar 14, 2023 at 11:30:52PM -0400, Maxim Cournoyer wrote: >> Hi, >> >> Leo Famulari writes: >> >> > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: >> >> Felix Lechner writes: >> >> > With the core-updates process now abandoned, I retitled the issue to >> >> >> >> Could you share the reference of that? I'm not against it, but our >> >> currently documented process still mention the good old staging and >> >> core-updates branches. >> > >> > At the Guix Days in February, we discussed the branching workflow and >> > reached a rough consensus that for non-core packages (defined in >> > %core-packages), we should try to adopt a more targeted "feature branch" >> > workflow. That's actually what we used to do, before we outgrew our old >> > build farm, after which we were barely able to build one branch at a >> > time (IIRC, we would stop building master in order to build core-updates >> > or staging). >> > >> > The discussion was summarized by Andreas here: >> > >> > https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html >> >> Thanks! I had missed it. It sounds promising! >> >> > Currently we are demo-ing this workflow in the wip-go-updates branch and >> > go-team Cuirass jobset. >> >> So the review happens first on the ML, then the changes land to the team >> branch, and then finally the feature branch gets merged to master? If >> the review has already happened and the package been tested (and built >> by QA), why is a feature branch needed? > > So we can group a couple of larger related changes together. I see; so it'd be useful for the integration of package changes impacting multiple others; some kind of staging or core-updates topic-focused branches. Simple leaf package updates could still be merged directly to master without going through the go-team branch, right? -- Thanks, Maxim
Re: Branch and release process (was: gnu: inetutils: Update to 2.4.)
"Leo Famulari" writes: > On Tue, Mar 14, 2023, at 23:30, Maxim Cournoyer wrote: >> Hi, >> >> Leo Famulari writes: >> >>> On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: Felix Lechner writes: > With the core-updates process now abandoned, I retitled the issue to Could you share the reference of that? I'm not against it, but our currently documented process still mention the good old staging and core-updates branches. >>> >>> At the Guix Days in February, we discussed the branching workflow and >>> reached a rough consensus that for non-core packages (defined in >>> %core-packages), we should try to adopt a more targeted "feature branch" >>> workflow. That's actually what we used to do, before we outgrew our old >>> build farm, after which we were barely able to build one branch at a >>> time (IIRC, we would stop building master in order to build core-updates >>> or staging). >>> >>> The discussion was summarized by Andreas here: >>> >>> https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html >> >> Thanks! I had missed it. It sounds promising! >> >>> Currently we are demo-ing this workflow in the wip-go-updates branch and >>> go-team Cuirass jobset. >> >> So the review happens first on the ML, then the changes land to the team >> branch, and then finally the feature branch gets merged to master? If >> the review has already happened and the package been tested (and built >> by QA), why is a feature branch needed? > > Because QA currently cannot process changes that cause more than 200 rebuilds. Note that this has been changing recently, and it's currently 600 builds per system [1]. 1: https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/guix-qa-frontpage/manage-builds.scm#n100 We can still increase it, but there's still more work needed on managing the builds and increasing the hardware available. signature.asc Description: PGP signature
Re: Branch and release process (was: gnu: inetutils: Update to 2.4.)
On Tue, Mar 14, 2023, at 23:30, Maxim Cournoyer wrote: > Hi, > > Leo Famulari writes: > >> On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: >>> Felix Lechner writes: >>> > With the core-updates process now abandoned, I retitled the issue to >>> >>> Could you share the reference of that? I'm not against it, but our >>> currently documented process still mention the good old staging and >>> core-updates branches. >> >> At the Guix Days in February, we discussed the branching workflow and >> reached a rough consensus that for non-core packages (defined in >> %core-packages), we should try to adopt a more targeted "feature branch" >> workflow. That's actually what we used to do, before we outgrew our old >> build farm, after which we were barely able to build one branch at a >> time (IIRC, we would stop building master in order to build core-updates >> or staging). >> >> The discussion was summarized by Andreas here: >> >> https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html > > Thanks! I had missed it. It sounds promising! > >> Currently we are demo-ing this workflow in the wip-go-updates branch and >> go-team Cuirass jobset. > > So the review happens first on the ML, then the changes land to the team > branch, and then finally the feature branch gets merged to master? If > the review has already happened and the package been tested (and built > by QA), why is a feature branch needed? Because QA currently cannot process changes that cause more than 200 rebuilds.
Re: Branch and release process (was: gnu: inetutils: Update to 2.4.)
On Tue, Mar 14, 2023 at 11:30:52PM -0400, Maxim Cournoyer wrote: > Hi, > > Leo Famulari writes: > > > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: > >> Felix Lechner writes: > >> > With the core-updates process now abandoned, I retitled the issue to > >> > >> Could you share the reference of that? I'm not against it, but our > >> currently documented process still mention the good old staging and > >> core-updates branches. > > > > At the Guix Days in February, we discussed the branching workflow and > > reached a rough consensus that for non-core packages (defined in > > %core-packages), we should try to adopt a more targeted "feature branch" > > workflow. That's actually what we used to do, before we outgrew our old > > build farm, after which we were barely able to build one branch at a > > time (IIRC, we would stop building master in order to build core-updates > > or staging). > > > > The discussion was summarized by Andreas here: > > > > https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html > > Thanks! I had missed it. It sounds promising! > > > Currently we are demo-ing this workflow in the wip-go-updates branch and > > go-team Cuirass jobset. > > So the review happens first on the ML, then the changes land to the team > branch, and then finally the feature branch gets merged to master? If > the review has already happened and the package been tested (and built > by QA), why is a feature branch needed? So we can group a couple of larger related changes together. > > My hope is that we can rewrite the relevant documentation in the coming > > months, as we learn from these early efforts. > > OK! Thanks for allowing me to catch up! > > -- > Thanks, > Maxim > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Branch and release process (was: gnu: inetutils: Update to 2.4.)
Hi, Leo Famulari writes: > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: >> Felix Lechner writes: >> > With the core-updates process now abandoned, I retitled the issue to >> >> Could you share the reference of that? I'm not against it, but our >> currently documented process still mention the good old staging and >> core-updates branches. > > At the Guix Days in February, we discussed the branching workflow and > reached a rough consensus that for non-core packages (defined in > %core-packages), we should try to adopt a more targeted "feature branch" > workflow. That's actually what we used to do, before we outgrew our old > build farm, after which we were barely able to build one branch at a > time (IIRC, we would stop building master in order to build core-updates > or staging). > > The discussion was summarized by Andreas here: > > https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html Thanks! I had missed it. It sounds promising! > Currently we are demo-ing this workflow in the wip-go-updates branch and > go-team Cuirass jobset. So the review happens first on the ML, then the changes land to the team branch, and then finally the feature branch gets merged to master? If the review has already happened and the package been tested (and built by QA), why is a feature branch needed? > My hope is that we can rewrite the relevant documentation in the coming > months, as we learn from these early efforts. OK! Thanks for allowing me to catch up! -- Thanks, Maxim
