"jgart" <jgart@dismail.de> writes:

> Hi Python Team, Guix Team at large, and Parenphilic Pythonistas,
>
> This long lived python-team branch as of today has a lot of git
> conflicts if you try to rebase and/or merge it on to master.
>
> What do you think if we discuss an alternative team branch policy for
> the future for feature branches that target master?
>
> Here's a tentative proposal, with an example: 
>
> Instead of having a single python-team branch, with a wide variety of
> new Python features, what if we had, a python-team feature branch that
> we work on relatively quickly?
>
> In other words, we avoid long lived branches but try to merge for
> example, a new python-team-sphinx branch as soon as the "Sphinx
> feature" is ready. This python-team-sphinx branch will only contain
> the work required to bump sphinx to the latest version that we'd like
> to support. The reason I use python-sphinx as an example is because
> the python-sphinx package requires a lot of rebuilds across many
> language ecosystems that use Sphinx for documentation purposes.
>
> I think that keeping the team branches focused on a particular team
> sub-feature within that team's scope and not using long-lived and
> largely scoped branches will avoid a ton of frustration trying to fix
> merge conflicts when/before we announce a request to merge.

This aligns with the current (and previous) guidance on managing
branches [1]. Providing there's a consistent topic for the branch, any
name is fine (e.g. python-team-sphinx is fine).

1: https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

I'm also hoping the requirement to create a guix-patches issue
requesting to merge the branch when it's created will help avoid the
long lived branches that we've had over the last year.