[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230607092210.62ace50f@kernel.org>
Date: Wed, 7 Jun 2023 09:22:10 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Saeed Mahameed <saeed@...nel.org>, "David S. Miller"
<davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet
<edumazet@...gle.com>, Saeed Mahameed <saeedm@...dia.com>,
netdev@...r.kernel.org, Tariq Toukan <tariqt@...dia.com>, Leon Romanovsky
<leonro@...dia.com>, linux-rdma@...r.kernel.org, Jiri Pirko
<jiri@...dia.com>
Subject: Re: [net-next 13/15] net/mlx5: Skip inline mode check after
mlx5_eswitch_enable_locked() failure
On Wed, 7 Jun 2023 17:46:09 +0200 Jiri Pirko wrote:
> >The combination of net-next and Fixes is always odd.
> >Why?
> >Either it's important enough to be a fix or its not important
> >and can go to net-next...
>
> As Jason wrote, this is a fix, but not -net worthy. I believe that
> "Fixes" tag should be there regardless of the target tree,
> it makes things easier to follow.
No it doesn't. Both as a maintainer and a person doing backports for
a production kernel I'm telling you that it doesn't. Fishing a
gazillion patches with random Fixes tags during the merge window,
2 months after they had been merged is *not* helping anyone.
And as it usually happens fixes people consider "not important enough"
are also usually trivial so very low risk of regression.
Maybe it makes it easier for you to stack patches but that's secondary..
--
pw-bot: cr
Powered by blists - more mailing lists