Hello, Am Sat, Jun 10, 2023 at 11:17:44PM -0400 schrieb Maxim Cournoyer: > > That to me says this should go to staging. > Correct. Except there's no staging branch anymore. I guess we should > create one? :-)
I would say it should go to a team branch; xsystem? Regardless of name, I think the idea behind the team branch concept is that a branch should regroup related changes (as much as possible), but in any case there should be an identified person or group of persons taking responsibility for shepherding the branch up to its merge; and for repairing potential breakage. So we could extend the concept to have a june-2023-disruptive-changes branch, with the aim of regrouping several maybe unrelated changes leading to bigger rebuilds (and identified responsibilities). We should not create a random branch where lots of big changes accumulate for which nobody takes responsibility. The changes suggested at https://issues.guix.gnu.org/63459 remove the staging and core-updates branches from the documentation. Does it leave open problems behind? One thing I wonder about is whether we should not rebase all team branches on master instead of merging master back in. In this way, at least the commits specific to a branch would be visible since they are on top; with the former merging concept of staging and core-updates, they would end up buried deep in the commit history. It could also help keeping changes focused. What do you think? Andreas
