GNU bug report logs - #71408
Request for merging "python-team" branch

Previous Next

Full log

View this message in rfc822 format

From: Christopher Baines <mail <at> cbaines.net>
To: "jgart" <jgart <at> dismail.de>
Cc: tanguy <at> bioneland.org, Sharlatan Hellseher <sharlatanus <at> gmail.com>, rprior <at> protonmail.com, me <at> bonfacemunyoki.com, Ludovic Courtès <ludo <at> gnu.org>, 71408 <at> debbugs.gnu.org, lars <at> 6xq.net, marius <at> gnu.org, Nicolas Graves <ngraves <at> ngraves.fr>
Subject: [bug#71408] Request for merging "python-team" branch
Date: Wed, 19 Jun 2024 14:45:22 +0100

[Message part 1 (text/plain, inline)]

"jgart" <jgart <at> 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.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.