all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: 70549@debbugs.gnu.org
Subject: [bug#70549] [PATCH] doc: Make changes to the handling of branches.
Date: Wed, 01 May 2024 18:20:57 +0200	[thread overview]
Message-ID: <874jbh5wra.fsf@gnu.org> (raw)
In-Reply-To: <94192a7b7eb8d2dc5008c20abcc3940b4474d800.1713964129.git.mail@cbaines.net> (Christopher Baines's message of "Wed, 24 Apr 2024 14:08:49 +0100")

Hi,

Christopher Baines <mail@cbaines.net> skribis:

> Require that you create a "Request to merge" issue when you create a branch,
> rather than when you wish to merge it.  This should help avoid this step being
> missed.

Excellent, I fully support this change!

A couple of questions/comments:

> Also, add information on how to manage these branches:
>
>  1. Suggest creating the branch from patches, rather than having a stateful
>  branch, since this should help to reduce complexity and avoid merges.

[...]

>  To help coordinate the merging of branches, you must create a new
> -guix-patches issue each time you wish to merge a branch (@pxref{The
> -Issue Tracker}).  The title of the issue requesting to merge a branch
> -should have the following format:
> +guix-patches issue each time you create a branch (@pxref{The Issue
> +Tracker}).  The title of the issue requesting to merge a branch should
> +have the following format:

This means someone on the team with commit access explicitly commits the
branch at the time they send the merge request email, right?

> +@item
> +The commits on the branch should be a combination of the patches
> +relevant to the branch.

Perhaps add: “; patches not related to the topic of the branch should go
elsewhere.”

> +@item
> +Avoid merging master in to the branch.  Prefer rebasing or re-creating
> +the branch on top of an updated master revision.
> +
> +@item
> +Minimise the changes on master that are missing on the branch prior to
> +merging the branch in to master.  Merging master in to the branch can be
> +appropriate for this purpose.

s/in to/into/

Thank you!

Ludo’.




  reply	other threads:[~2024-05-01 16:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 13:08 [bug#70549] [PATCH] doc: Make changes to the handling of branches Christopher Baines
2024-05-01 16:20 ` Ludovic Courtès [this message]
2024-05-01 17:07   ` Christopher Baines
2024-05-08 11:29 ` [bug#70549] [PATCH v2] " Christopher Baines
2024-05-22 14:33   ` Simon Tournier
2024-05-22 16:04   ` bug#70549: " 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=874jbh5wra.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=70549@debbugs.gnu.org \
    --cc=mail@cbaines.net \
    /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.