Re: Jumping the queue: merge r-team before python-team?

[Simon Tournier]

Hi Ricardo,

On Fri, 11 Apr 2025 at 12:45, Ricardo Wurmus <rekado@elephly.net> wrote:
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> the r-team branch has been ready for weeks.  It has only accumulated
>> more changes (like the upgrade of R itself) as it has been sitting in
>> the queue.  What do you think about letting this branch jump the
>> queue ahead of python-team?
>
> There has now been a new R release while the branch has been 
> waiting for a merge.  I'll update the r-team branch again, but I 
> think it is unfortunate that I can no longer update R in a timely 
> fashion.

I agree.  And FWIW I tried to raise this concern when we switched to
team’s branches and especially when we removed the core-updates branch.

Aside, please note that the deletion of core-updates and having more
teams have not reduced the number of grafts – probably even worse since
now we do not exactly know how to proceed without the core-updates
branch. :-)

Well, copy/pasting [1]:

        Let try to not waste resource.  I think we could have a policy when a
        branch contains “heavy” rebuilds.  Because we cannot continuously
        rebuild the world. ;-)

        Somehow, the team of this “heavy” rebuild branch says: “hey build train
        of branch X starts soon”, meaning the team is ready and the state of the
        branch X looks good so it require to set up the CI, i.e., the team is
        going to trigger more than 1000 rebuilds.  The message “build train of
        branch X starts soon” is sent to guix-devel and one week is let to the
        other teams to rebase their own branch onto branch X, if they have
        something to build, are ready, etc.

        The team who asked the “build train” is responsible for crossing the
        final line (the merge to master) and also responsible to synchronize
        with the wagons, e.g., by sending some updates about how is going the
        world rebuild, when the final merge is planned, etc.

        If no one takes this train, no big deal because a next train is probably
        going to start soon. ;-)

And I am not sure this proposal would help with the current r-team +
python-team upgrades.  That’s said, I’m convinced we need a better
policy for merging in good cooperation such upgrades.

Hum, the strategy is not fully clear for me.  What would it be a better
strategy for you?

Cheers,
simon

1: Naming “build train” instead of “merge train”?
Simon Tournier <zimon.toutoune@gmail.com>
Mon, 09 Sep 2024 19:28:57 +0200
id:878qw0sply.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2024-09
https://yhetil.org/guix/878qw0sply.fsf@gmail.com