unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 63459@debbugs.gnu.org
Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy.
Date: Tue, 23 May 2023 18:28:18 +0100	[thread overview]
Message-ID: <87pm6rlys0.fsf@cbaines.net> (raw)
In-Reply-To: <87y1lkzc98.fsf@gnu.org>

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


Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Thanks for this initiative!
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> 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): Rewrite branching strategy.
>
> [...]
>
>> +Changes to packages with 300 dependent packages or less can be pushed to
>> +the @code{master} branch.
>> +
>> +Larger changes should be first pushed to a branch other than
>> +@code{master}. This allows for testing and for the build farms to
>> +process the changes prior to being pushed to the @code{master} branch.
>
> I’d be more specific:
>
>   Larger changes should first be pushed to a topic branch other than
>   @code{master}; the set of changes should be consistent---e.g., ``GNOME
>   update'', ``NumPy update'', etc.  This allows for testing: the branch
>   will automatically show up at
>   @indicateurl{https://qa.guix.gnu.org/branch/@var{branch}}, with an
>   indication of its build status on various platforms.
>
> “Automatic” is a bit of an overstatement; that sentence probably needs
> to be tweaked.  :-)  But I think it’s good to link to the QA platform to
> make things more concrete.

That sounds fine to me. Everything apart from starting the builds is
already automatic, and I want to automate that through the issues
described here.

>> +To help coordinate the merging of branches, you must create a new
>> +guix-patches issue each time you wish to merge a branch. These issues
>                                                           ^
> + (@pxref{Tracking Bugs and Patches})
>
>> +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 blocked by the issue previously at the back of the queue.
>
> s/blocked/@dfn{blocked}/
>
> Perhaps add a footnote or paren stating how to “block” an issue in
> Debbugs?

Yeah, I'll try and write something.

>> +Normally branches will be merged in a ``first come, first merged''
>> +manor, tracked through the guix-patches issues. If you agree a different
>
> s/manor/manner/
> s/agree a/agree on a/
>
>> +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.
>> +
>> +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.
>
> This is a bit technical.  How can I know “which branch is at the front
> of the queue”?  Even as a seasoned Debbugs users, I’m not sure what I’m
> supposed to do here.  Do you think we could provide ready to use
> commands (debbugs.el or ‘mumi’) or at least a sequence of steps to
> follow?

So, I think there's two technical hurdles to overcome here. The first is
identifying the issues for merging branches, maybe for that we can set
out a format for the title of the bug, but I'm very open to
suggestions. Any way of identifying the open issues should be usable
through debbugs.el and mumi.

The second hurdle is the queuing behaviour, which I think the blocking
behaviour is a natural fit for. Maybe the tooling is lacking but I think
that can be addressed.

I want the qa-frontpage to display the queue of branches (and issues) in
a clear way, as well as providing links to make changes (as it does for
marking issues as moreinfo).

> Last but not least: two spaces after end-of-sentence period please.  :-)
>
> This is mostly about tweaking words; I think this is a great step
> forward, very much in line with what was discussed in February at the
> Guix Days.  Thank you!

Great, thanks for taking a look!

Chris

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

  reply	other threads:[~2023-05-23 17:54 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 [this message]
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
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=87pm6rlys0.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=63459@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /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).