workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Jeff Johnson <jeff.johnson@oss.qualcomm.com>, workflows@vger.kernel.org
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: Is there an integrated b4 + patchwork guide for maintainers?
Date: Sun, 14 Sep 2025 14:44:01 +0200	[thread overview]
Message-ID: <2910e736-b74c-4b6c-aa8a-85adcc3cc680@kernel.org> (raw)
In-Reply-To: <972dd368-282a-4255-9b88-6324c1924512@oss.qualcomm.com>

On 12/09/2025 01:54, Jeff Johnson wrote:
> On 7/17/2024 12:30 PM, Jeff Johnson wrote:
>> I'm in the process of taking over ath.git maintainer activities from Kalle. He
>> has shared his workflow, but much of it is based upon using Stacked Git (STG)
>> and a patchwork script he authored. I seems like many (most?) maintainers are
>> now using b4, and Kalle fully supports me using it, so I just want to see if
>> there is a guide or sample workflow for using b4 along with patchwork. I'd
>> like to adopt a proven workflow rather than stumbling around on my own.
> 
> I sent this over a year ago (using my former credentials). I did not receive
> any responses at that time, so I just cobbled things together.
> 
> In light of current discussion about using Link: tags, and related discussion
> about how multi-commit series should be treated (applied linearly or merged
> from a dev branch), it seems timely to re-ask the question. Is there a guide


These two examples are not really dependent on the workflow - whether
your upstream rebases your patches or not, will be the same regardless
you use b4 or old `mutt | git am` method.

> or recommended sample workflow for using b4 along with patchwork?


Therefore maybe precise a bit the question, because it can really be
understood in many ways. For example I understood as:
1. Get the list of patches from Patchwork with pwclient and feed to
mutt/neomutt.
2. Go through them.
3. b4 shazam accepted patches, which will mark them as accepted in
Patchwork (see b4 config about Patchwork integration or my talk from
2023 LPC)
4. Respond through rest of them and then delete downloaded mboxes/maildir.

But maybe you ask about linux-next rules (although hardly relevant to
b4...) so that's why I did not respond. It's just too vague.

Best regards,
Krzysztof


      parent reply	other threads:[~2025-09-14 12:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-17 19:30 Jeff Johnson
2025-09-11 23:54 ` Jeff Johnson
2025-09-12  1:22   ` dan.j.williams
2025-09-14 12:44   ` Krzysztof Kozlowski [this message]

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

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

  git send-email \
    --in-reply-to=2910e736-b74c-4b6c-aa8a-85adcc3cc680@kernel.org \
    --to=krzk@kernel.org \
    --cc=jeff.johnson@oss.qualcomm.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=workflows@vger.kernel.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox