From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Christopher Baines <mail@cbaines.net>
Cc: 63459@debbugs.gnu.org
Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy.
Date: Sun, 11 Jun 2023 22:37:53 -0400 [thread overview]
Message-ID: <878rcp8kxq.fsf_-_@gmail.com> (raw)
In-Reply-To: <eb3daa3c66abb0f80f18c05da07a836f235cdb06.1686234207.git.mail@cbaines.net> (Christopher Baines's message of "Thu, 8 Jun 2023 15:23:28 +0100")
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. ...
> +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?
> +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 :-).
Thanks for working on completing the documentation of the new work flow.
--
Maxim
next prev parent reply other threads:[~2023-06-12 2:39 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 ` Maxim Cournoyer [this message]
2023-06-12 9:01 ` [bug#63459] [PATCH] doc: Rewrite " Christopher Baines
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=878rcp8kxq.fsf_-_@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=63459@debbugs.gnu.org \
--cc=mail@cbaines.net \
/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).