All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, pabeni@redhat.com
Subject: Re: [PATCH net-next 00/11] wireguard updates for 6.19
Date: Thu, 4 Dec 2025 12:43:31 -0500	[thread overview]
Message-ID: <aTHIQ2ZuuQutREXf@zx2c4.com> (raw)
In-Reply-To: <20251201203713.58118d7e@kernel.org>

Hi Jakub,

On Mon, Dec 01, 2025 at 08:37:13PM -0800, Jakub Kicinski wrote:
> FWIW we do still ask for patches to be posted to the list. But some
> folks like to do _both_ that and include a branch/signed tag in the
> cover letter to pull.

You manage a zillion patches from a million people, and so your process
of doing things takes precedent over whatever hairbrained ideas I have,
obviously. But I thought I'd ask about this anyway (and if it's too
annoying for you to even respond to, don't worry, and I'll continue
doing things as normal, happily, without even a grumble).

Here is how things work for submissions to Linus:
1. People post things to the list (myself included). They get discussed.
   Revisions get posted. Eventually things settle down and Reviewed-by
   lines come in.
2. I queue up the settled patches in one of my trees.
3. Eventually, I send a PULL to Linus for said tree.
4. Result: the patches originally posted on the list wind up in Linus'
   tree, and on Lore, there is one single thread that the patch came from.

Here is how things work for submissions to netdev:
1. People post things to the list (myself included). They get discussed.
   Revisions get posted. Eventually things settle down and Reviewed-by
   lines come in.
2. I queue up the settled patches in one of my trees.
3. Eventually, I send the patches back out to you, and then you queue
   them up in net[-next].
4. Result: the patches originally posted on the list wind up in your
   tree, and on Lore, there are now two threads for each patch -- the
   original where it was discussed, and this new process-generated one,
   and they're identical.

The idea of sending a pull instead of step 3 would be to avoid the
duplication. But it sounds like if I did a pull, you'd want
pull+patches, continuing the duplication? What if, instead, the pull
request just had the global diff of the whole pull? So it wouldn't be a
total duplicate, but there'd still be some extra confirmation for you
(which is I assume what the duplication is all about).

Or... I just keep doing things in the normal way that they've been done
for years, which clearly works and doesn't present a real issue for
anybody. :) I don't want to change a process that clearly works for you.
This always just struck me as a peculiarity, so I thought this was an
occasion to mention it.

Jason

  reply	other threads:[~2025-12-04 17:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01  2:28 [PATCH net-next 00/11] wireguard updates for 6.19 Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 01/11] wireguard: netlink: enable strict genetlink validation Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 02/11] wireguard: netlink: validate nested arrays in policy Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 03/11] wireguard: netlink: use WG_KEY_LEN in policies Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 04/11] wireguard: netlink: convert to split ops Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 05/11] wireguard: netlink: lower .maxattr for WG_CMD_GET_DEVICE Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 06/11] netlink: specs: add specification for wireguard Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 07/11] wireguard: uapi: move enum wg_cmd Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 08/11] wireguard: uapi: move flag enums Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 09/11] wireguard: uapi: generate header with ynl-gen Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 10/11] tools: ynl: add sample for wireguard Jason A. Donenfeld
2025-12-01 21:00   ` Asbjørn Sloth Tønnesen
2025-12-02  3:09     ` Jason A. Donenfeld
2025-12-01  2:28 ` [PATCH net-next 11/11] wireguard: netlink: generate netlink code Jason A. Donenfeld
2025-12-01 23:07 ` [PATCH net-next 00/11] wireguard updates for 6.19 Jakub Kicinski
2025-12-02  3:19   ` Jason A. Donenfeld
2025-12-02  4:37     ` Jakub Kicinski
2025-12-04 17:43       ` Jason A. Donenfeld [this message]
2025-12-02  4:40 ` patchwork-bot+netdevbpf

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=aTHIQ2ZuuQutREXf@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.