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, 4 Mar 2022 18:47:06 +1100 (AEDT)
From:   Finn Thain <fthain@linux-m68k.org>
To:     Joe Perches <joe@perches.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
cc:     Konrad Wilhelm Kleine <kkleine@redhat.com>,
        Tom Rix <trix@redhat.com>,
        Bart Van Assche <bvanassche@acm.org>,
        kashyap.desai@broadcom.com, sumit.saxena@broadcom.com,
        shivasharan.srikanteshwara@broadcom.com, jejb@linux.ibm.com,
        martin.petersen@oracle.com, Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        megaraidlinux.pdl@broadcom.com, scsi <linux-scsi@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>, llvm@lists.linux.dev
Subject: Re: [PATCH] scsi: megaraid: cleanup formatting of megaraid
In-Reply-To: <7368bc3ea6dece01004c3e0c194abb0d26d4932b.camel@perches.com>
Message-ID: <1dccb035-5f85-d9fd-7c10-3f9cd395deeb@linux-m68k.org>
References: <20220127151945.1244439-1-trix@redhat.com>  <d26d4bd8-b5e1-f4d5-b563-9bc4dd384ff8@acm.org>  <0adde369-3fd7-3608-594c-d199cce3c936@redhat.com>  <e3ae392a16491b9ddeb1f0b2b74fdf05628b1996.camel@perches.com>  <46441b86-1d19-5eb4-0013-db1c63a9b0a5@redhat.com>
  <8dd05afd-0bb9-c91b-6393-aff69f1363e1@redhat.com>  <233660d0-1dee-7d80-1581-2e6845bf7689@linux-m68k.org>  <CABRYuGk+1AGpvfkR7=LTCm+bN4kt55fwQnQXCjidSXWxuMWsiQ@mail.gmail.com>  <95f5be1d-f5f3-478-5ccb-76556a41de78@linux-m68k.org> 
 <CANiq72kOJh_rGg6cT+S833HYqwHnZJzZss8v+kQDcgz_cZUfBQ@mail.gmail.com> <7368bc3ea6dece01004c3e0c194abb0d26d4932b.camel@perches.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Thu, 3 Mar 2022, Joe Perches wrote:

> On Fri, 2022-03-04 at 00:17 +0100, Miguel Ojeda wrote:
> > On Thu, Mar 3, 2022 at 11:44 PM Finn Thain wrote:
> > > 
> > > Others might argue that they should always be changed from,
> > > 
> > > /*
> > >  * this style
> > >  * of multiline comment
> > >  */
> > > 
> > > to
> > > 
> > > /* this style
> > >  * of multiline comment
> > >  */
> > 
> > In general, for things that the coding style guide talks about, we 
> > should follow them, even if some subsystems do not (they can always 
> > override in their folder if they really, really want it). So, here for 
> > instance, the first one should be used.
> 
> It's up to individual maintainers to each decide on what might be 
> considered unnecessary churn for the subsystems they control.
> 
> One argument is that churn leads to difficulty in backporting fixes to 
> older 'stable' versions.
> 
> I think the churn argument is overstated.
> 

If you would have clang-format override the committer and retrospectively 
apply subsystem style rules (rather than the rules used by a majority of 
subsystems or those preferred by Linus for example) it would add friction 
to code re-use, movement, comparison, any tree-wide program 
transformation, and also subsystem boundary changes.

Per-subsystem style rules are inherently contentious and therefore good 
candidates for the "leave alone" functionality discussed in the issue 
tracker.