John Kehayias <john.kehayias@protonmail.com> writes:

>> I've now merged these changes as
>> 0ea096ae23fa81f05ce97e5e61c15647c0a475ec.
>>
>> You can now see the updated Commit Policy on the website [1] (you might
>> need to force a refresh), as well as the new section on managing patches
>> and branches [2].
>>
>> 1: <https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html#Commit-Policy>
>> 2: <https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html>
>>
>
> Thanks for these changes! Question on branches (sorry if this was
> covered in a previous thread, but now that we have new language in the
> manual I figure this is a good place): do we have a convention on
> branch names and subject headers for emailing patches for the branch?
> e.g. does [PATCH <branch> 1/3] do anything on the QA end?

On the names of branches, there's some typical names like XXXX-team, or
wip-XXXX but really it's up to you.

QA doesn't currently support applying patches to anything other than the
master branch, but that's something that should probably be addressed at
some point. I'd encourage you to do whatever you think is useful here,
then hopefully QA can use that to act appropriately.

> Or does the section about branch building for once patches are pushed
> to a branch on Savannah?

I'm not sure what you're asking here.

> Does that mean pushing to a branch should follow the same 1-2 week
> review allowing QA builds? I guess patch series are always built
> together on QA but wondering if there is anything else to be aware of
> or needs mentioning to keep things tidy and clear.

Those durations mentioned in the commit policy [1] are intended to allow
for human review. For QA, it doesn't need to be time based as it can
report it's progress. Obviously it does need a bit of time to check
things, but I prefer to leave it up to people to assess the changes and
any information provided by QA and decide when it's appropriate to push.

1: https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html#Commit-Policy

On keeping things clear, I think with branches I'm hoping the issue
tracker can help with this, which is why there's now a strong
requirement to create a guix-patches issue when you want to merge a
branch, and use those issues to manage the timing.

For those issues, there's currently a convention of using the following
title: `Request for merging "XXXX" branch` e.g. [2]. That helps QA find
these issues and act accordingly, but of course if someone comes up with
a better way of naming these issues, we can just adjust the code in the
qa-frontpage.

2: https://issues.guix.gnu.org/63713
3: https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/guix-qa-frontpage/branch.scm#n63

Thanks for your questions :)

Chris