From: Christopher Baines <mail@cbaines.net>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 63459@debbugs.gnu.org
Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy.
Date: Mon, 12 Jun 2023 10:01:21 +0100 [thread overview]
Message-ID: <87edmhxcy3.fsf@cbaines.net> (raw)
In-Reply-To: <878rcp8kxq.fsf_-_@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3760 bytes --]
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hi Christopher,
>
> Christopher Baines <mail@cbaines.net> writes:
>
>> Move away from using staging and core-updates, and make the strategy
>> independant of branch names.
>>
>> Keep the 300 dependent threshold for changes to master, as I don't have any
>> specific reason to change this.
>>
>> Most importantly, require using guix-patches issues to coordinate merging of
>> the branches, as I think that'll address the key issues that have shown up
>> recently where it's been unclear which branch should be merged next.
>>
>> * doc/contributing.texi (Submitting Patches): Move the branching strategy to a
>> new Managing Patches and Branches section.
>> (Managing Patches and Branches): New section.
>> (Commit Policy): Simplify through referencing the new Managing Patches and
>> Branches section.
>
> [...]
>
>> +
>> +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}). These issues indicate the order in which the branches
>> +should be merged, so take a look at the open issues for merging branches
>> +and mark the issue you create as @dfn{blocked} by the issue previously
>> +at the back of the queue@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.}.
>
> Maybe by default, since the strategy would be "first come, first
> merged", we can forego with the 'block' tags, as issues will already be
> posted in the order (and given an increasing number) they should be
> merged? Then the nitty-gritty details of micro-managing block tags can
> be mentioned only when they are useful, e.g. ...
That sounds fine to me.
>> +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 which other issues. Therefore, to know which branch
>> +is at the front of the queue, look for the issue which isn't blocked by
>> +any other branch merges.
>
> ... here. Can anyone merge the branches of someone else that posted
> them to the tracker but 'hasn't gotten around' to merge them to the repo
> (e.g. gone on vacation), although they were fully QA'd, blocking every
> other branch merge?
I've moved the blocking stuff down.
As for the merging of branches that others have pushed, I'm not sure
there's consensus regarding this. Personally I would like to see this,
being able to merge other committers changes, I raised it on guix-devel
recently [1].
1: https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00263.html
>> +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
>> +the necessary testing to have happened.
>
> What does that mean concretely? How can I track the build status of a
> change? Please at least mention the QA badge which is visible from
> issues.guix.gnu.org and perhaps other tricks I'm unaware of :-).
It's intentionally quite high level and non-concrete. Maybe we'll get to
the point in the future where we have more specific requirements to meet
before merging a branch, but I don't think we have that yet.
qa.guix.gnu.org/branch/NAME is linked to above, and I've added another
link to it here. The QA badge currently doesn't work for branches, but
I'd like to get it working.
I've sent a v4 now, thanks for taking a look!
Chris
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]
next prev parent reply other threads:[~2023-06-12 9:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-12 7:55 [bug#63459] [PATCH] doc: Rewrite the branching strategy Christopher Baines
2023-05-12 8:04 ` Christopher Baines
2023-05-19 13:22 ` Ludovic Courtès
2023-05-23 17:28 ` Christopher Baines
2023-05-31 9:46 ` Christopher Baines
2023-05-31 9:41 ` [bug#63459] [PATCH v2] doc: Move and rewrite " Christopher Baines
2023-06-06 15:27 ` [bug#63459] [PATCH] doc: Rewrite " Ludovic Courtès
2023-06-08 14:23 ` [bug#63459] [PATCH v3] doc: Move and rewrite " Christopher Baines
2023-06-12 2:37 ` [bug#63459] [PATCH] doc: Rewrite " Maxim Cournoyer
2023-06-12 9:01 ` Christopher Baines [this message]
2023-06-12 12:20 ` Maxim Cournoyer
2023-06-12 19:53 ` Christopher Baines
2023-06-12 9:01 ` [bug#63459] [PATCH v4] doc: Move and rewrite " Christopher Baines
2023-06-12 20:19 ` bug#63459: [PATCH] doc: Rewrite " 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=87edmhxcy3.fsf@cbaines.net \
--to=mail@cbaines.net \
--cc=63459@debbugs.gnu.org \
--cc=maxim.cournoyer@gmail.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).