Linux block layer
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Phillip Potter <phil@philpotter.co.uk>
Cc: linux-block@vger.kernel.org
Subject: Re: [PATCH 1/1] cdrom: Add missing blank lines after declarations
Date: Mon, 16 Oct 2023 15:11:53 -0600	[thread overview]
Message-ID: <df197ee9-9a06-42c8-9633-896685b56328@kernel.dk> (raw)
In-Reply-To: <ZS2l/R2cBqhdVNkR@equinox>

On 10/16/23 3:07 PM, Phillip Potter wrote:
> On Mon, Oct 16, 2023 at 02:53:06PM -0600, Jens Axboe wrote:
>> On 10/16/23 2:47 PM, Phillip Potter wrote:
>>> From: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
>>>
>>> Add missing blank lines after declarations to fix warning found by
>>> checkpatch.pl script.
>>
>> Let's please not do this. It's fine to run checkpatch on new patches to
>> ensure that you don't make mistakes, but this is just useless churn.
>> Even worse:
>>
> Hi Jens,
> 
> So to be clear, I should not accept patches that do cleanup like this
> in future unless there are other substantive changes? I also build
> tested the patch as per normal.

Right. May be fine if actual fixes are being made, then do it as a prep
patch or something. That sometimes happens, you fix something and notice
that some styling is off and then fix that too.

>>> @@ -1202,6 +1204,7 @@ static int check_for_audio_disc(struct cdrom_device_info *cdi,
>>>  {
>>>          int ret;
>>>  	tracktype tracks;
>>> +
>>>  	cd_dbg(CD_OPEN, "entering check_for_audio_disc\n");
>>>  	if (!(cdi->options & CDO_CHECK_TYPE))
>>>  		return 0;
>>
>> This int ret is using spaces and not a tab, why even make a newline
>> change and not sort that out too?
>>
> 
> Yes, good point. Given the patch only consisted of new lines though, I
> didn't think it a bad one. If this is the policy though, I will be
> stricter in future of course.

It's just pointless churn, which is the objection. Now granted for cdrom
the risk of conflict isn't that large, as it doesn't really see any
changes. But in general this is the kind of stuff that prevents stable
backports from just applying automatically. I view it similarly to
spelling fixes, and that kind of stuff. Is the style wrong? It is. But
it's not worth fixing seperately.

-- 
Jens Axboe


      reply	other threads:[~2023-10-16 21:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-16 20:47 [PATCH 0/1] cdrom: cleanup patch for inclusion Phillip Potter
2023-10-16 20:47 ` [PATCH 1/1] cdrom: Add missing blank lines after declarations Phillip Potter
2023-10-16 20:53   ` Jens Axboe
2023-10-16 21:07     ` Phillip Potter
2023-10-16 21:11       ` Jens Axboe [this message]

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=df197ee9-9a06-42c8-9633-896685b56328@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=phil@philpotter.co.uk \
    /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