Subject: [bug#71408] Request for merging "python-team" branch

From: "jgart" <[email-masked]>
Date: Tue, 18 Jun 2024 20:46:47 +0000

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.

We can then focus our focused efforts on iterating over preparing major Python features and packages that require large amounts rebuilds.

WDYT?

jgart