"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.