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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> 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?

Rebasing only really works if a single person works on the branch, since
it rewrites history.  So it doesn't seem very team friendly.  Also,
rebasing causes the PGP-signed commits to be resigned with the key of
the people of does the rebase, which obfuscates the origin seal
somewhat.

I think we should continue to prefer merging, but minimizing this to
only when it's truly required, as Linus suggests for branches
maintainers (where it's suggested to not sync with the main branch to
avoid getting unrelated/untested changes).  If the branches are
short-lived that shouldn't be (common) problem anyway.

What do you think?

-- 
Thanks,
Maxim