Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Andreas Enge <andreas@enge.fr>]

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