public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Greg KH <greg@kroah.com>, Vinod Koul <vkoul@kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	Sing-Han Chen <singhanc@nvidia.com>,
	Wayne Chang <waynec@nvidia.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: duplicate patches in the phy-next tree
Date: Thu, 19 Jan 2023 12:33:32 -0500	[thread overview]
Message-ID: <Y8l+7KfRdPweMGWd@mit.edu> (raw)
In-Reply-To: <Y8lJiJHHcUO7MXQY@orome>

On Thu, Jan 19, 2023 at 02:45:44PM +0100, Thierry Reding wrote:
> 
> This has been a recurring theme, so I'm trying to get a better
> understanding of what people expect here. Some maintainers want to see
> a whole series for a single feature (in this case it was Tegra234 USB
> support) even if it crosses multiple subsystems/trees. This has the
> advantage that patches can be arranged such that all dependencies are
> resolved. Other maintainers like things to be split up so that patches
> are easier to pick up.

Yeah, that's a problem I've seen work both ways.  For example, there
was the "Convert del_timer*() to timer_shutdown*()" series, which was
sent out both as a treewide patch as well as piecewise for each
subsystem.  The patches haven't been applied yet, and it's been on my
todo list to figure out (a) whether I should wait and for it to go in
via some other tree, and (b) whether it's safe to apply it standalone
for ext4, and that's what the patch author was intending.

Personally, I'm happy to do it both ways, especially for fairly
trivial treewide changes.  If it's complex enough that it's going to
cause merge conflict headaches, that would be different, but very
often, it's just 1 or 2 line changes in a very large number of
subsystems.

Cheers,

						- Ted

  reply	other threads:[~2023-01-19 17:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19  4:31 linux-next: duplicate patches in the phy-next tree Stephen Rothwell
2023-01-19  6:12 ` Vinod Koul
2023-01-19  6:54   ` Greg KH
2023-01-19 13:45     ` Thierry Reding
2023-01-19 17:33       ` Theodore Ts'o [this message]
2023-01-20 14:02       ` Greg KH

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=Y8l+7KfRdPweMGWd@mit.edu \
    --to=tytso@mit.edu \
    --cc=greg@kroah.com \
    --cc=jonathanh@nvidia.com \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=singhanc@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=vkoul@kernel.org \
    --cc=waynec@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox