mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Alejandro Colomar <alx+linux-hardening@kernel.org>,
	Bartosz Golaszewski <brgl@kernel.org>
Cc: Alejandro Colomar <alx@kernel.org>,
	linux-hardening@vger.kernel.org,
	Andreas Schwab <schwab@linux-m68k.org>,
	Andy Shevchenko <andy@kernel.org>,
	Daniel Scally <djrscally@gmail.com>,
	Danilo Krummrich <dakr@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Joe Perches <joe@perches.com>, Johan Hovold <johan@kernel.org>,
	Kees Cook <kees@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Len Brown <lenb@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linus Walleij <linusw@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Saravana Kannan <saravanak@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tom Zanussi <zanussi@kernel.org>,
	linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2 0/2] Add strprefix() and fix a bug with it
Date: Thu, 5 Nov 2026 16:21:02 +0100	[thread overview]
Message-ID: <5001d8c2-2334-48bd-bc95-6b33e3922a46@kernel.org> (raw)
In-Reply-To: <auyOkL1Vb1iKicS9@devuan>

On 05/11/2026 15:16, Alejandro Colomar wrote:
> Hi Bart,
> 
>> Date: 2026-11-05 15:01:22+0100
>> From: Bartosz Golaszewski <brgl@kernel.org>
>>
> [...]
>>
>> I have no idea what causes it but I'm getting so many patches lately
>> that are subsequent iterations of a series sent with In-Reply-To: header
>> pointing to a previous thread.
> 
> I don't know what others do, but in my case it's a conscious manual
> action.  I use --in-reply-to in git-format-patch(1) to make all
> revisions of patch sets be descendants of the cover letter of v1.
> 
> We do this in the Linux man-pages, as it helps me keep track of all
> revisions of a patch set easily in mutt(1), without having to follow
> links or use more-complex tools like b4(1).

My mailbox gets 200-300 patches per day (not counting replies), so I
have no idea how that could be manageable if all versions of some series
were threaded to itself. Some old thread popping up to the top,
half-read, deeply nested like 20-deep indentation?

But even in second workflow, reviewing individual patches via b4 or mutt
after shazaming (my main workflow of DT) not via inbox, would get huge
irrelevant thread of past discussions requiring me to look for stuff
actually for the review. How to find actual patch to review in this huge
thread? I tried many times, takes much more time than reviewing simply
current version.

b4 is not so more complex, honestly it's just new interface and after
learning a few new commands is straightforward and easy. And solves
successfully, without creating noise or problems to others, all problems
which you might be trying to solve: referencing earlier versions, easy
comparing between any version, collecting trailers, sending nice
thank-you letters with commit and tree references etc.

I believe there should be no excuse for modern maintainer to not use b4
in the workflow. The same BTW for submitters of anything bigger than
3-patch series.

And for maintainers, along with `b4 review tui` above statement will
only grow.

Final note, you will receive template-nags from several maintainers if
you keep send them series threaded to past versions, but of course there
are also folks who are fine with that.


Best regards,
Krzysztof

  parent reply	other threads:[~2026-11-05 15:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 11:12 [PATCH v1 " Alejandro Colomar
2026-11-05 11:13 ` [PATCH v1 1/2] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-05 11:27   ` Andy Shevchenko
2026-11-05 12:28     ` Alejandro Colomar
2026-11-05 16:14   ` Steven Rostedt
2026-11-05 16:33     ` Alejandro Colomar
2026-11-05 16:50       ` Steven Rostedt
2026-11-05 17:46         ` Alejandro Colomar
2026-11-05 18:08           ` Andy Shevchenko
2026-11-05 18:12             ` Andy Shevchenko
2026-11-05 11:13 ` [PATCH v1 2/2] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-05 11:24 ` [PATCH v1 0/2] Add strprefix() and fix a bug with it Andy Shevchenko
2026-11-05 11:38   ` Alejandro Colomar
2026-11-05 11:59     ` Andy Shevchenko
2026-11-05 12:30 ` Bartosz Golaszewski
2026-11-05 12:49   ` Alejandro Colomar
2026-11-05 12:46 ` [PATCH v2 " Alejandro Colomar
2026-11-05 12:46   ` [PATCH v2 1/2] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-05 12:51     ` Geert Uytterhoeven
2026-11-05 13:12       ` Alejandro Colomar
2026-11-05 12:46   ` [PATCH v2 2/2] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-05 14:01   ` [PATCH v2 0/2] Add strprefix() and fix a bug with it Bartosz Golaszewski
2026-11-05 14:16     ` Alejandro Colomar
2026-11-05 14:42       ` Andy Shevchenko
2026-11-05 15:06         ` Alejandro Colomar
2026-11-05 15:00       ` Bartosz Golaszewski
2026-11-05 15:14         ` Alejandro Colomar
2026-11-05 15:21       ` Krzysztof Kozlowski [this message]
2026-11-05 16:27         ` Steven Rostedt
2026-11-05 16:30           ` Krzysztof Kozlowski
2026-11-05 16:42         ` Alejandro Colomar

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=5001d8c2-2334-48bd-bc95-6b33e3922a46@kernel.org \
    --to=krzk@kernel.org \
    --cc=alx+linux-hardening@kernel.org \
    --cc=alx@kernel.org \
    --cc=andy@kernel.org \
    --cc=brgl@kernel.org \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=djrscally@gmail.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=joe@perches.com \
    --cc=johan@kernel.org \
    --cc=kees@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lenb@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=saravanak@kernel.org \
    --cc=schwab@linux-m68k.org \
    --cc=torvalds@linux-foundation.org \
    --cc=zanussi@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

all inboxes | Powered by JetHome®