unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: John Kehayias <john.kehayias@protonmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Changes to the branching/commit policy
Date: Sat, 17 Jun 2023 10:57:59 +0100	[thread overview]
Message-ID: <87edmal7jk.fsf@cbaines.net> (raw)
In-Reply-To: <871qiaslx6.fsf@protonmail.com>

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


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

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

  reply	other threads:[~2023-06-17 10:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08 14:24 Changes to the branching/commit policy Christopher Baines
2023-06-09 10:10 ` [bug#63459] " Andreas Enge
2023-06-11  9:37   ` Christopher Baines
2023-06-11  9:53     ` Andreas Enge
2023-06-12  1:28     ` [bug#63459] " Maxim Cournoyer
2023-06-12 20:23 ` Christopher Baines
2023-06-17  5:22   ` John Kehayias
2023-06-17  9:57     ` Christopher Baines [this message]
2023-06-19 18:39       ` John Kehayias
2023-06-20  3:52         ` 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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87edmal7jk.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=guix-devel@gnu.org \
    --cc=john.kehayias@protonmail.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).