Re: [PATCH] drivers/ata: fix repeated words in comments

[<Conor.Dooley@microchip.com>]

On 08/09/2022 14:02, James Bottomley wrote:
> [You don't often get email from james.bottomley@hansenpartnership.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, 2022-09-08 at 12:56 +0000, Conor.Dooley@microchip.com wrote:
>> On 08/09/2022 13:49, wangjianli wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>> know the content is safe
>>>
>>> Delete the redundant word 'in'.
>>>
>>> Signed-off-by: wangjianli <wangjianli@cdjrlc.com>
>>> ---
>>>    drivers/ata/libata-eh.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
>>> index 7c128c89b454..ca865a95cf24 100644
>>> --- a/drivers/ata/libata-eh.c
>>> +++ b/drivers/ata/libata-eh.c
>>> @@ -863,7 +863,7 @@ void ata_eh_fastdrain_timerfn(struct timer_list
>>> *t)
>>>     *
>>>     *     Set ATA_PFLAG_EH_PENDING and activate fast drain if
>>> @fastdrain
>>>     *     is non-zero and EH wasn't pending before.  Fast drain
>>> ensures
>>> - *     that EH kicks in in timely manner.
>>> + *     that EH kicks in timely manner.
>>
>> Hey wangjianli,
>> This does not look like the right fix to me.. To me, it looks like it
>> should be s/in in/in in a/.
>>
>> If you're using an automated tool, which I can only assume you are,
>> to find these typos it'd be a good idea to check the output for
>> correctness prior to sending patches.
> 
> And it would also have been nice to accommodate the exact same feedback
> last time these patches were posted:
> 
> https://lore.kernel.org/all/cec12e246d7151f6041bf553629a3047e81d4afe.camel@HansenPartnership.com/
> 
> It's really disappointing you haven't accommodated any feedback either
> into your bot or the patches it sends.  Not doing so really does render
> this work largely useless.

I've been replying a bit to these typo "fixes" that are not fixes since
I am a native speaker and maybe some things get lost in translation but
I have pretty much never got responses from the patch submitters.

It's a little bit frustrating since fairly often, the fix is not to
remove the dupe, but instead s/in in/is in/ etc.

If there's a tool running against this stuff but maintainers are not
applying the patches as the "fixes" are not fixes it's only going to
keep generating the same patches over and over is it not?