[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53d0efe0-f970-49ed-939b-d3a53dc7db86@intel.com>
Date: Wed, 3 Dec 2025 16:50:31 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>, Andrew Lunn
<andrew@...n.ch>
CC: Heiner Kallweit <hkallweit1@...il.com>, Alexandre Torgue
<alexandre.torgue@...s.st.com>, Andrew Lunn <andrew+netdev@...n.ch>, "David
S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, "Heiko
Stuebner" <heiko@...ech.de>, Jakub Kicinski <kuba@...nel.org>,
<linux-arm-kernel@...ts.infradead.org>, <linux-rockchip@...ts.infradead.org>,
<linux-stm32@...md-mailman.stormreply.com>, Maxime Coquelin
<mcoquelin.stm32@...il.com>, <netdev@...r.kernel.org>, Paolo Abeni
<pabeni@...hat.com>
Subject: Re: [PATCH RFC net-next 00/15] net: stmmac: rk: cleanups galore
On 12/1/2025 8:38 AM, Russell King (Oracle) wrote:
> So, in future, I'm going to take the attitude that I will NAK
> contributions if I think there's a side issue that the contributor
> should also be addressing until that side issue is addressed.
>
> This shouldn't be necessary, I wish this weren't necessary, and I wish
> people could be relied upon to do the right thing, but apparently it is
> going to take a stick (not merging their patches) to get them to co-
> operate. More fool me for trusting someone to do something.
>
Yep this is unfortunately a reality of dealing with many contributors.
While its frustrating to require this.. If you don't, and end up never
getting things fixed the end result is worse.
As a maintainer, sometimes the only leverage you have is when someone
wants a contribution to merge. Balancing so that relevant improvements
and work get done while not being so harsh that contributors stop
returning is a difficult problem.
> I now have a couple of extra patches addressing my point raised in
> that email... which I myself shouldn't have had to write.
>
:(
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists