all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andreas Enge <andreas@enge.fr>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: Christopher Baines <mail@cbaines.net>, guix-devel@gnu.org
Subject: Re: Feature branches
Date: Wed, 10 May 2023 11:21:16 +0200	[thread overview]
Message-ID: <ZFtiDCQ7BAQPwUQ0@jurong> (raw)
In-Reply-To: <87bkiuvju6.fsf@gmail.com>

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	other threads:[~2023-05-10  9:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <168347913021.32190.10808857919894440138@vcs2.savannah.gnu.org>
     [not found] ` <20230507170531.26A00C22F14@vcs2.savannah.gnu.org>
2023-05-08  1:41   ` 04/09: gnu: mesa: Update to 23.0.3 Christopher Baines
2023-05-08 12:08     ` Maxim Cournoyer
2023-05-08 12:56       ` Christopher Baines
2023-05-08 15:01         ` Maxim Cournoyer
2023-05-08 16:33           ` Feature branches (was: 04/09: gnu: mesa: Update to 23.0.3) Andreas Enge
2023-05-08 17:01             ` Feature branches Maxim Cournoyer
2023-05-10  9:21               ` Andreas Enge [this message]
2023-05-10 13:23                 ` Maxim Cournoyer
2023-05-10 13:40                   ` Andreas Enge
2023-05-10 13:55                     ` Andreas Enge
2023-05-11  4:49                       ` Maxim Cournoyer
2023-05-08 17:15             ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-05-10  9:11               ` Andreas Enge
2023-05-10 11:30                 ` Christopher Baines
2023-05-08 16:39           ` 04/09: gnu: mesa: Update to 23.0.3 Christopher Baines
2023-05-09  4:37     ` John Kehayias
2023-05-09  8:39       ` Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZFtiDCQ7BAQPwUQ0@jurong \
    --to=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.