On Tue, Mar 14, 2023, at 23:30, 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?
Because QA currently cannot process changes that cause more than 200 rebuilds.
