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