Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 29 Jul 2022 10:11:00 +0200
From:   Jiri Pirko <jiri@resnulli.us>
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     Li zeming <zeming@nfschina.com>, jhs@mojatatu.com,
        xiyou.wangcong@gmail.com, davem@davemloft.net, edumazet@google.com,
        pabeni@redhat.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/net/act: Remove temporary state variables 
Message-ID: <YuOWFM/xRaJSuX5M@nanopsycho>
References: <20220727094146.5990-1-zeming@nfschina.com>
 <20220728201556.230b9efd@kernel.org>
 <YuN+i2WtzfA0wDQb@nanopsycho>
 <20220728235121.43bedc43@kernel.org>
 <YuOFd2oqA1Cbl+at@nanopsycho>
 <20220729001842.5bc9f0b2@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220729001842.5bc9f0b2@kernel.org>
Precedence: bulk

Fri, Jul 29, 2022 at 09:18:42AM CEST, kuba@kernel.org wrote:
>On Fri, 29 Jul 2022 09:00:07 +0200 Jiri Pirko wrote:
>> >> What backports do you have in mind exactly?  
>> >
>> >Code backports. I don't understand the question.  
>> 
>> Code backports of what where?
>> Are you talking about:
>> 1) mainline kernels
>> 2) distrubutions kernels? Or even worse, in-house kernels of companies?
>> 
>> If 2), I believe it is not relevant for the upstream discussion, at all.
>
>Fixes and stable. Frankly it's just a generic justification 

Was there a significant value of breakages for net and stable backports
in past?


>to discourage people from sending subjective code cleanups.
>I'd never argue for the benefit of (2) :)

Uff, for a second, it did sound like it :)


>
>There's been a string of patches cleaning up return values
>of functions in the last few days. If people have a lot of

Well, I think it is good to send a patch to clean something up when you
spot it. If you don't do it, someone else might do it again in the
future anyway.

Plus there is one good reason at least to do this kinds of cleanups.
People tend to copy&paste code without thinking twice. So if you clean
it up here, it might not get copied into other code. That's good.


>time on their hands they should go do something useful, like
>converting netdev features to a bitmap. Hell, go fix W=1 warnings, 
>even easier.

Random spot&clean is hardly comparable to this.


>
>The time spent reviewing those "cleanups" adds up, and I suspect
>there's hundreds of places they can be applied. Hence my question
>about automation...