guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature branches


From: Andreas Enge
Subject: Re: Feature branches
Date: Wed, 10 May 2023 11:21:16 +0200

Hello,

Am Mon, May 08, 2023 at 01:01:05PM -0400 schrieb Maxim Cournoyer:
> - I'd make the team branches permanent; e.g. the 'gnome-team' branch
>   would always exist, and get synced periodically to master (when enough
>   built/deemed stable).  This should reduce the overhead of constantly
>   having to adjust the Cuirass specification jobs and serve as an
>   integration point for the team (the Cuirass job specs would be defined
>   declaratively in the guix-maintenance repository).

I would argument the other way round :)  For instance, I would now remove
the rust-team branch so that it is clear that currently there is no work
on rust. As soon as there is again, the team could spin off a new branch
from master. This would avoid having branches around of which we do not
know any more what they contain, and whether they contain unmerged changes.

$ git branch -a | grep rust
  remotes/origin/rekados-rust-queue
  remotes/origin/rust-team
  remotes/origin/wip-cross-built-rust
  remotes/origin/wip-rekado-rust-team
  remotes/origin/wip-rust

Can any of these be removed? Or brought up to shape?

Notice that this is independent of the cuirass specifications (I think).
I think we could keep the specifications on cuirass, but am not totally
sure what happens when the branch does not exist. Probably nothing. And
then it should be picked up again once it is recreated.

> - branches judged too experimental to be merged into their team branch
>   could be branched from it, with a name such as 'gnome-team/feature-x'
>   to make it obvious where it should be merged when deemed ready.
>   Cuirass job specifications for such short lived branches would be
>   created manually using the Cuirass web interface (users need to be
>   authorized as can be done following
>   https://issues.guix.gnu.org/63375).
> I don't think team branches should be merged together at any point,
> ideally, to avoid loosing the benefits of feature branches (limited
> scope).

Agreed, if we start branching from branches and merging back, we will
probably lose overview.

With my take of not having permanent team branches, it might not even be
necessary to branch from team branches.

Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]