Hi Efraim, Efraim Flashner <efr...@flashner.co.il> writes:
> On Tue, Mar 14, 2023 at 11:30:52PM -0400, Maxim Cournoyer wrote: >> Hi, >> >> Leo Famulari <l...@famulari.name> writes: >> >> > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: >> >> Felix Lechner <felix.lech...@lease-up.com> 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
