[bug#70549] [PATCH] doc: Make changes to the handling of branches.

[bug#70549] [PATCH] doc: Make changes to the handling of branches.

[Christopher Baines]

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.

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.

 2. Require that branches don't have unnecessary changes, since this increases
 the risks of conflicts with other branches.

 3. Suggest avoiding merges since these create a more complicated Git history.

 4. Suggest that the branch be up to date before merging, as this helps avoid
 the combination of master plus the branch differing significantly from the
 branch alone.

Finally, require that the branch be deleted once they're merged.  This
prepares for the branch being created again.

* doc/contributing.texi (Managing Patches and Branches): Make changes to the
handling of branches.

Change-Id: Ib9419c6df94f485475bd6f147e82ea254e76cec2
---
 doc/contributing.texi | 59 ++++++++++++++++++++++++++++++-------------
 1 file changed, 42 insertions(+), 17 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index ad0f5a8ecd..038ed7d040 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -2290,9 +2290,9 @@ Managing Patches and Branches
 
 @cindex feature branches, coordination
 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:
 
 @cindex merge requests, template
 @example
@@ -2300,20 +2300,42 @@ Managing Patches and Branches
 @end example
 
 The @url{https://qa.guix.gnu.org/, QA infrastructure} recognizes such
-issues and lists the merge requests on its main page.  Normally branches
-will be merged in a ``first come, first merged'' manner, tracked through
-the guix-patches issues.
-
-If you agree on a different order with those involved, you can track
-this by updating which issues block@footnote{You can mark an issue as
-blocked by another by emailing @email{control@@debbugs.gnu.org} with the
-following line in the body of the email: @code{block XXXXX by YYYYY}.
-Where @code{XXXXX} is the number for the blocked issue, and @code{YYYYY}
-is the number for the issue blocking it.} which other issues.
-Therefore, to know which branch is at the front of the queue, look for
-the oldest issue, or the issue that isn't @dfn{blocked} by any other
-branch merges.  An ordered list of branches with the open issues is
-available at @url{https://qa.guix.gnu.org}.
+issues and lists the merge requests on its main page.  The following
+points apply to managing these branches:
+
+@enumerate
+@item
+The commits on the branch should be a combination of the patches
+relevant to the branch.  It should be possible to re-create the branch
+by starting from master and applying the relevant patches.
+
+@item
+Any changes that can be made on the master branch, should be made on the
+master branch.  If a commit can be split to apply part of the changes on
+master, this is good to do.
+
+@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.
+@end enumerate
+
+Normally branches will be merged in a ``first come, first merged''
+manner, tracked through the guix-patches issues.  If you agree on a
+different order with those involved, you can track this by updating
+which issues block@footnote{You can mark an issue as blocked by another
+by emailing @email{control@@debbugs.gnu.org} with the following line in
+the body of the email: @code{block XXXXX by YYYYY}.  Where @code{XXXXX}
+is the number for the blocked issue, and @code{YYYYY} is the number for
+the issue blocking it.} which other issues.  Therefore, to know which
+branch is at the front of the queue, look for the oldest issue, or the
+issue that isn't @dfn{blocked} by any other branch merges.  An ordered
+list of branches with the open issues is available at
+@url{https://qa.guix.gnu.org}.
 
 Once a branch is at the front of the queue, wait until sufficient time
 has passed for the build farms to have processed the changes, and for
@@ -2321,6 +2343,9 @@ Managing Patches and Branches
 @indicateurl{https://qa.guix.gnu.org/branch/@var{branch}} to see
 information on some builds and substitute availability.
 
+Once the branch has been merged, the issue should be closed and the
+branch deleted.
+
 @node Debbugs User Interfaces
 @subsection Debbugs User Interfaces
 

base-commit: e2ba93373a29ddf5d5754368957e89f3b426bb0a
-- 
2.41.0

[bug#70549] [PATCH] doc: Make changes to the handling of branches.

[Ludovic Courtès]

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’.

[bug#70549] [PATCH] doc: Make changes to the handling of branches.

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>>  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?

There's intentionally no mention of teams here, but that's pretty much
it. I'm not intending this to be super strict, like forgetting the issue
then creating it a day or two later is fine.

You mention commit access, and that does make me think that maybe we
should include something saying that if you don't have commit access,
please go ahead and create the issue, and in it ask for the branch to be
created. With the expectation that they'll be someone with commit access
to help with creating and managing the branch.

>> +@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.”

Good idea.

>> +@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/

Good spot.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

[bug#70549] [PATCH v2] doc: Make changes to the handling of branches.

[Christopher Baines]

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.

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.

 2. Require that branches don't have unnecessary changes, since this increases
 the risks of conflicts with other branches.

 3. Suggest that the branch not be stateful, and it's just a combination of
 patches.

 4. Suggest avoiding merges since these create a more complicated Git history.

 5. Suggest that the branch be up to date before merging, as this helps avoid
 the combination of master plus the branch differing significantly from the
 branch alone.

Finally, require that the branch be deleted once they're merged.  This
prepares for the branch being created again.

* doc/contributing.texi (Managing Patches and Branches): Make changes to the
handling of branches.

Change-Id: Ib9419c6df94f485475bd6f147e82ea254e76cec2
---
 doc/contributing.texi | 68 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 51 insertions(+), 17 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 66f4e86d0a..ecff6300bf 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -2298,9 +2298,9 @@ Managing Patches and Branches
 
 @cindex feature branches, coordination
 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:
 
 @cindex merge requests, template
 @example
@@ -2308,20 +2308,51 @@ Managing Patches and Branches
 @end example
 
 The @url{https://qa.guix.gnu.org/, QA infrastructure} recognizes such
-issues and lists the merge requests on its main page.  Normally branches
-will be merged in a ``first come, first merged'' manner, tracked through
-the guix-patches issues.
-
-If you agree on a different order with those involved, you can track
-this by updating which issues block@footnote{You can mark an issue as
-blocked by another by emailing @email{control@@debbugs.gnu.org} with the
-following line in the body of the email: @code{block XXXXX by YYYYY}.
-Where @code{XXXXX} is the number for the blocked issue, and @code{YYYYY}
-is the number for the issue blocking it.} which other issues.
-Therefore, to know which branch is at the front of the queue, look for
-the oldest issue, or the issue that isn't @dfn{blocked} by any other
-branch merges.  An ordered list of branches with the open issues is
-available at @url{https://qa.guix.gnu.org}.
+issues and lists the merge requests on its main page.  The following
+points apply to managing these branches:
+
+@enumerate
+@item
+The commits on the branch should be a combination of the patches
+relevant to the branch.  Patches not related to the topic of the branch
+should go elsewhere.
+
+@item
+Any changes that can be made on the master branch, should be made on the
+master branch.  If a commit can be split to apply part of the changes on
+master, this is good to do.
+
+@item
+It should be possible to re-create the branch by starting from master
+and applying the relevant patches.
+
+@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.  This means that the state of the
+branch better reflects the state of master should the branch be merged.
+
+@item
+If you don't have commit access, create the ``Request for merging''
+issue and request that someone creates the branch.  Include a list of
+issues/patches to include on the branch.
+@end enumerate
+
+Normally branches will be merged in a ``first come, first merged''
+manner, tracked through the guix-patches issues.  If you agree on a
+different order with those involved, you can track this by updating
+which issues block@footnote{You can mark an issue as blocked by another
+by emailing @email{control@@debbugs.gnu.org} with the following line in
+the body of the email: @code{block XXXXX by YYYYY}.  Where @code{XXXXX}
+is the number for the blocked issue, and @code{YYYYY} is the number for
+the issue blocking it.} which other issues.  Therefore, to know which
+branch is at the front of the queue, look for the oldest issue, or the
+issue that isn't @dfn{blocked} by any other branch merges.  An ordered
+list of branches with the open issues is available at
+@url{https://qa.guix.gnu.org}.
 
 Once a branch is at the front of the queue, wait until sufficient time
 has passed for the build farms to have processed the changes, and for
@@ -2329,6 +2360,9 @@ Managing Patches and Branches
 @indicateurl{https://qa.guix.gnu.org/branch/@var{branch}} to see
 information on some builds and substitute availability.
 
+Once the branch has been merged, the issue should be closed and the
+branch deleted.
+
 @node Debbugs User Interfaces
 @subsection Debbugs User Interfaces
 

base-commit: 2bea3f256209c4f92a2ace28b45d1f452a2b51ba
-- 
2.41.0

[bug#70549] [PATCH v2] doc: Make changes to the handling of branches.

[Simon Tournier]

Hi,

On mer., 08 mai 2024 at 12:29, Christopher Baines <mail@cbaines.net> wrote:

>  doc/contributing.texi | 68 ++++++++++++++++++++++++++++++++-----------
>  1 file changed, 51 insertions(+), 17 deletions(-)
>
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index 66f4e86d0a..ecff6300bf 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi

I am probably a bit late.  All this LGTM! :-)

Thank you for this work.

Cheers,
simon

bug#70549: [PATCH v2] doc: Make changes to the handling of branches.

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 90 bytes --]

These changes have now been pushed to master as
4955589f2f343e1862dfae7831d1fc548811d59b.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]