All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22  8:04 ` Jilin Yuan
  0 siblings, 0 replies; 26+ messages in thread
From: Jilin Yuan @ 2022-06-22  8:04 UTC (permalink / raw)
  To: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel; +Cc: Jilin Yuan

Delete the redundant word 'to'.

Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
---
 arch/arc/mm/cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 5446967ea98d..84fe78c41c37 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -750,7 +750,7 @@ static inline void arc_slc_enable(void)
  *  -In SMP, if hardware caches are coherent
  *
  * There's a corollary case, where kernel READs from a userspace mapped page.
- * If the U-mapping is not congruent to to K-mapping, former needs flushing.
+ * If the U-mapping is not congruent to K-mapping, former needs flushing.
  */
 void flush_dcache_page(struct page *page)
 {
-- 
2.36.1


^ permalink raw reply related	[flat|nested] 26+ messages in thread

* [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22  8:04 ` Jilin Yuan
  0 siblings, 0 replies; 26+ messages in thread
From: Jilin Yuan @ 2022-06-22  8:04 UTC (permalink / raw)
  To: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel; +Cc: Jilin Yuan

Delete the redundant word 'to'.

Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
---
 arch/arc/mm/cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 5446967ea98d..84fe78c41c37 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -750,7 +750,7 @@ static inline void arc_slc_enable(void)
  *  -In SMP, if hardware caches are coherent
  *
  * There's a corollary case, where kernel READs from a userspace mapped page.
- * If the U-mapping is not congruent to to K-mapping, former needs flushing.
+ * If the U-mapping is not congruent to K-mapping, former needs flushing.
  */
 void flush_dcache_page(struct page *page)
 {
-- 
2.36.1


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22  8:04 ` Jilin Yuan
@ 2022-06-22  8:30   ` Bagas Sanjaya
  -1 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-22  8:30 UTC (permalink / raw)
  To: Jilin Yuan; +Cc: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On Wed, Jun 22, 2022 at 04:04:23PM +0800, Jilin Yuan wrote:
> Delete the redundant word 'to'.
> 
> Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
> ---
>  arch/arc/mm/cache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
> index 5446967ea98d..84fe78c41c37 100644
> --- a/arch/arc/mm/cache.c
> +++ b/arch/arc/mm/cache.c
> @@ -750,7 +750,7 @@ static inline void arc_slc_enable(void)
>   *  -In SMP, if hardware caches are coherent
>   *
>   * There's a corollary case, where kernel READs from a userspace mapped page.
> - * If the U-mapping is not congruent to to K-mapping, former needs flushing.
> + * If the U-mapping is not congruent to K-mapping, former needs flushing.
>   */
>  void flush_dcache_page(struct page *page)
>  {

The patch is OK, but its subject is wrong.

The patch above isn't fixing any syntax errors, but rather minor cleanup.
The subject should have been "Remove duplicate 'to' in the
flush_dcache_page() comment".

I think that this kind of cleanup patches (typofixes) are best done
as part of **actual** work on the code in question (for example
refactoring or fixing build errors).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22  8:30   ` Bagas Sanjaya
  0 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-22  8:30 UTC (permalink / raw)
  To: Jilin Yuan; +Cc: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On Wed, Jun 22, 2022 at 04:04:23PM +0800, Jilin Yuan wrote:
> Delete the redundant word 'to'.
> 
> Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
> ---
>  arch/arc/mm/cache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
> index 5446967ea98d..84fe78c41c37 100644
> --- a/arch/arc/mm/cache.c
> +++ b/arch/arc/mm/cache.c
> @@ -750,7 +750,7 @@ static inline void arc_slc_enable(void)
>   *  -In SMP, if hardware caches are coherent
>   *
>   * There's a corollary case, where kernel READs from a userspace mapped page.
> - * If the U-mapping is not congruent to to K-mapping, former needs flushing.
> + * If the U-mapping is not congruent to K-mapping, former needs flushing.
>   */
>  void flush_dcache_page(struct page *page)
>  {

The patch is OK, but its subject is wrong.

The patch above isn't fixing any syntax errors, but rather minor cleanup.
The subject should have been "Remove duplicate 'to' in the
flush_dcache_page() comment".

I think that this kind of cleanup patches (typofixes) are best done
as part of **actual** work on the code in question (for example
refactoring or fixing build errors).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22  8:30   ` Bagas Sanjaya
@ 2022-06-22  8:42     ` Shahab Vahedi
  -1 siblings, 0 replies; 26+ messages in thread
From: Shahab Vahedi @ 2022-06-22  8:42 UTC (permalink / raw)
  To: Bagas Sanjaya, Jilin Yuan
  Cc: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/22/22 10:30, Bagas Sanjaya wrote:

> I think that this kind of cleanup patches (typofixes) are best done
> as part of **actual** work on the code in question (for example
> refactoring or fixing build errors).

Amen!

-- 
Shahab

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22  8:42     ` Shahab Vahedi
  0 siblings, 0 replies; 26+ messages in thread
From: Shahab Vahedi @ 2022-06-22  8:42 UTC (permalink / raw)
  To: Bagas Sanjaya, Jilin Yuan
  Cc: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/22/22 10:30, Bagas Sanjaya wrote:

> I think that this kind of cleanup patches (typofixes) are best done
> as part of **actual** work on the code in question (for example
> refactoring or fixing build errors).

Amen!

-- 
Shahab
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22  8:42     ` Shahab Vahedi
@ 2022-06-22  9:16       ` Julia Lawall
  -1 siblings, 0 replies; 26+ messages in thread
From: Julia Lawall @ 2022-06-22  9:16 UTC (permalink / raw)
  To: Shahab Vahedi
  Cc: Bagas Sanjaya, Jilin Yuan, vgupta, Julia.Lawall, rdunlap,
	linux-snps-arc, linux-kernel



On Wed, 22 Jun 2022, Shahab Vahedi wrote:

> On 6/22/22 10:30, Bagas Sanjaya wrote:
>
> > I think that this kind of cleanup patches (typofixes) are best done
> > as part of **actual** work on the code in question (for example
> > refactoring or fixing build errors).
>
> Amen!

So code that is fine will have typos forever?  Fixing typos in comments
doesn't break git blame for the following code.  And typos in comments
give a bad impression about the state of the code in general.

But that is a general statement.  Perhaps this code does particularly need
work.

julia

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22  9:16       ` Julia Lawall
  0 siblings, 0 replies; 26+ messages in thread
From: Julia Lawall @ 2022-06-22  9:16 UTC (permalink / raw)
  To: Shahab Vahedi
  Cc: Bagas Sanjaya, Jilin Yuan, vgupta, Julia.Lawall, rdunlap,
	linux-snps-arc, linux-kernel



On Wed, 22 Jun 2022, Shahab Vahedi wrote:

> On 6/22/22 10:30, Bagas Sanjaya wrote:
>
> > I think that this kind of cleanup patches (typofixes) are best done
> > as part of **actual** work on the code in question (for example
> > refactoring or fixing build errors).
>
> Amen!

So code that is fine will have typos forever?  Fixing typos in comments
doesn't break git blame for the following code.  And typos in comments
give a bad impression about the state of the code in general.

But that is a general statement.  Perhaps this code does particularly need
work.

julia

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22  9:16       ` Julia Lawall
@ 2022-06-22  9:25         ` Shahab Vahedi
  -1 siblings, 0 replies; 26+ messages in thread
From: Shahab Vahedi @ 2022-06-22  9:25 UTC (permalink / raw)
  To: Julia Lawall, Shahab Vahedi
  Cc: Bagas Sanjaya, Jilin Yuan, vgupta, rdunlap, linux-snps-arc, linux-kernel

On 6/22/22 11:16, Julia Lawall wrote:
> 
> 
> On Wed, 22 Jun 2022, Shahab Vahedi wrote:
> 
>> On 6/22/22 10:30, Bagas Sanjaya wrote:
>>
>>> I think that this kind of cleanup patches (typofixes) are best done
>>> as part of **actual** work on the code in question (for example
>>> refactoring or fixing build errors).
>>
>> Amen!
> 
> So code that is fine will have typos forever?  Fixing typos in comments
> doesn't break git blame for the following code.  And typos in comments
> give a bad impression about the state of the code in general.

Of course not! Documentation is as important as the code, if not even more.
However, fixing typos to increase your commit counts to a reputable project
is not fine either. For instance, many of these proposed fixes are targeting
one single typo at a time. Couldn't they just be sent altogether!?!

-- 
Shahab

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22  9:25         ` Shahab Vahedi
  0 siblings, 0 replies; 26+ messages in thread
From: Shahab Vahedi @ 2022-06-22  9:25 UTC (permalink / raw)
  To: Julia Lawall, Shahab Vahedi
  Cc: Bagas Sanjaya, Jilin Yuan, vgupta, rdunlap, linux-snps-arc, linux-kernel

On 6/22/22 11:16, Julia Lawall wrote:
> 
> 
> On Wed, 22 Jun 2022, Shahab Vahedi wrote:
> 
>> On 6/22/22 10:30, Bagas Sanjaya wrote:
>>
>>> I think that this kind of cleanup patches (typofixes) are best done
>>> as part of **actual** work on the code in question (for example
>>> refactoring or fixing build errors).
>>
>> Amen!
> 
> So code that is fine will have typos forever?  Fixing typos in comments
> doesn't break git blame for the following code.  And typos in comments
> give a bad impression about the state of the code in general.

Of course not! Documentation is as important as the code, if not even more.
However, fixing typos to increase your commit counts to a reputable project
is not fine either. For instance, many of these proposed fixes are targeting
one single typo at a time. Couldn't they just be sent altogether!?!

-- 
Shahab
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22  9:25         ` Shahab Vahedi
@ 2022-06-22  9:38           ` Julia Lawall
  -1 siblings, 0 replies; 26+ messages in thread
From: Julia Lawall @ 2022-06-22  9:38 UTC (permalink / raw)
  To: Shahab Vahedi
  Cc: Bagas Sanjaya, Jilin Yuan, vgupta, rdunlap, linux-snps-arc, linux-kernel



On Wed, 22 Jun 2022, Shahab Vahedi wrote:

> On 6/22/22 11:16, Julia Lawall wrote:
> >
> >
> > On Wed, 22 Jun 2022, Shahab Vahedi wrote:
> >
> >> On 6/22/22 10:30, Bagas Sanjaya wrote:
> >>
> >>> I think that this kind of cleanup patches (typofixes) are best done
> >>> as part of **actual** work on the code in question (for example
> >>> refactoring or fixing build errors).
> >>
> >> Amen!
> >
> > So code that is fine will have typos forever?  Fixing typos in comments
> > doesn't break git blame for the following code.  And typos in comments
> > give a bad impression about the state of the code in general.
>
> Of course not! Documentation is as important as the code, if not even more.
> However, fixing typos to increase your commit counts to a reputable project
> is not fine either. For instance, many of these proposed fixes are targeting
> one single typo at a time. Couldn't they just be sent altogether!?!

I have the impression that the person is just trying to figure out the
patch submission process.  For example, the subject lines are not
formatter in the standard way (I sent the person a private email about
that).  Perhaps just let him know about how you would rather have received
the patches.

julia

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22  9:38           ` Julia Lawall
  0 siblings, 0 replies; 26+ messages in thread
From: Julia Lawall @ 2022-06-22  9:38 UTC (permalink / raw)
  To: Shahab Vahedi
  Cc: Bagas Sanjaya, Jilin Yuan, vgupta, rdunlap, linux-snps-arc, linux-kernel



On Wed, 22 Jun 2022, Shahab Vahedi wrote:

> On 6/22/22 11:16, Julia Lawall wrote:
> >
> >
> > On Wed, 22 Jun 2022, Shahab Vahedi wrote:
> >
> >> On 6/22/22 10:30, Bagas Sanjaya wrote:
> >>
> >>> I think that this kind of cleanup patches (typofixes) are best done
> >>> as part of **actual** work on the code in question (for example
> >>> refactoring or fixing build errors).
> >>
> >> Amen!
> >
> > So code that is fine will have typos forever?  Fixing typos in comments
> > doesn't break git blame for the following code.  And typos in comments
> > give a bad impression about the state of the code in general.
>
> Of course not! Documentation is as important as the code, if not even more.
> However, fixing typos to increase your commit counts to a reputable project
> is not fine either. For instance, many of these proposed fixes are targeting
> one single typo at a time. Couldn't they just be sent altogether!?!

I have the impression that the person is just trying to figure out the
patch submission process.  For example, the subject lines are not
formatter in the standard way (I sent the person a private email about
that).  Perhaps just let him know about how you would rather have received
the patches.

julia

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22  9:38           ` Julia Lawall
@ 2022-06-22 13:20             ` Bagas Sanjaya
  -1 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-22 13:20 UTC (permalink / raw)
  To: Julia Lawall, Shahab Vahedi
  Cc: Jilin Yuan, vgupta, rdunlap, linux-snps-arc, linux-kernel

On 6/22/22 16:38, Julia Lawall wrote:
>>> So code that is fine will have typos forever?  Fixing typos in comments
>>> doesn't break git blame for the following code.  And typos in comments
>>> give a bad impression about the state of the code in general.
>>
>> Of course not! Documentation is as important as the code, if not even more.
>> However, fixing typos to increase your commit counts to a reputable project
>> is not fine either. For instance, many of these proposed fixes are targeting
>> one single typo at a time. Couldn't they just be sent altogether!?!
> 
> I have the impression that the person is just trying to figure out the
> patch submission process.  For example, the subject lines are not
> formatter in the standard way (I sent the person a private email about
> that).  Perhaps just let him know about how you would rather have received
> the patches.

In recent times I had seen many typofix patches sent to LKML. You can see most
of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches
have been merged, though.

What I say as starter thread is "ideal" scenario as described in
Documentation/process/2.Process.rst; that is we prefer to see these minor
fixes as part of real patches work (say refactoring), rather than just being
trivial patches.

But what most reviewers here missed is how these typos are found? I guess
these can be from codespell or some other tools, or even manual review,
then send the fixes en mass.

Take a look at "fix typo in a comment" aka "delete redundant word" patches
at [1], [2], [3]. and [4].

[1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxiang@cdjrlc.com/
[2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxiang@cdjrlc.com/
[3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxiang@cdjrlc.com/
[4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxiang@cdjrlc.com/

IMHO, these patches should have been in a single, consolidated patch, since
these strip duplicate (hence redundant) word (single logical change).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22 13:20             ` Bagas Sanjaya
  0 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-22 13:20 UTC (permalink / raw)
  To: Julia Lawall, Shahab Vahedi
  Cc: Jilin Yuan, vgupta, rdunlap, linux-snps-arc, linux-kernel

On 6/22/22 16:38, Julia Lawall wrote:
>>> So code that is fine will have typos forever?  Fixing typos in comments
>>> doesn't break git blame for the following code.  And typos in comments
>>> give a bad impression about the state of the code in general.
>>
>> Of course not! Documentation is as important as the code, if not even more.
>> However, fixing typos to increase your commit counts to a reputable project
>> is not fine either. For instance, many of these proposed fixes are targeting
>> one single typo at a time. Couldn't they just be sent altogether!?!
> 
> I have the impression that the person is just trying to figure out the
> patch submission process.  For example, the subject lines are not
> formatter in the standard way (I sent the person a private email about
> that).  Perhaps just let him know about how you would rather have received
> the patches.

In recent times I had seen many typofix patches sent to LKML. You can see most
of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches
have been merged, though.

What I say as starter thread is "ideal" scenario as described in
Documentation/process/2.Process.rst; that is we prefer to see these minor
fixes as part of real patches work (say refactoring), rather than just being
trivial patches.

But what most reviewers here missed is how these typos are found? I guess
these can be from codespell or some other tools, or even manual review,
then send the fixes en mass.

Take a look at "fix typo in a comment" aka "delete redundant word" patches
at [1], [2], [3]. and [4].

[1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxiang@cdjrlc.com/
[2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxiang@cdjrlc.com/
[3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxiang@cdjrlc.com/
[4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxiang@cdjrlc.com/

IMHO, these patches should have been in a single, consolidated patch, since
these strip duplicate (hence redundant) word (single logical change).

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22 13:20             ` Bagas Sanjaya
@ 2022-06-22 13:46               ` Julia Lawall
  -1 siblings, 0 replies; 26+ messages in thread
From: Julia Lawall @ 2022-06-22 13:46 UTC (permalink / raw)
  To: Bagas Sanjaya
  Cc: Julia Lawall, Shahab Vahedi, Jilin Yuan, vgupta, rdunlap,
	linux-snps-arc, linux-kernel



On Wed, 22 Jun 2022, Bagas Sanjaya wrote:

> On 6/22/22 16:38, Julia Lawall wrote:
> >>> So code that is fine will have typos forever?  Fixing typos in comments
> >>> doesn't break git blame for the following code.  And typos in comments
> >>> give a bad impression about the state of the code in general.
> >>
> >> Of course not! Documentation is as important as the code, if not even more.
> >> However, fixing typos to increase your commit counts to a reputable project
> >> is not fine either. For instance, many of these proposed fixes are targeting
> >> one single typo at a time. Couldn't they just be sent altogether!?!
> >
> > I have the impression that the person is just trying to figure out the
> > patch submission process.  For example, the subject lines are not
> > formatter in the standard way (I sent the person a private email about
> > that).  Perhaps just let him know about how you would rather have received
> > the patches.
>
> In recent times I had seen many typofix patches sent to LKML. You can see most
> of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches
> have been merged, though.
>
> What I say as starter thread is "ideal" scenario as described in
> Documentation/process/2.Process.rst; that is we prefer to see these minor
> fixes as part of real patches work (say refactoring), rather than just being
> trivial patches.
>
> But what most reviewers here missed is how these typos are found? I guess
> these can be from codespell or some other tools, or even manual review,
> then send the fixes en mass.
>
> Take a look at "fix typo in a comment" aka "delete redundant word" patches
> at [1], [2], [3]. and [4].
>
> [1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxiang@cdjrlc.com/
> [2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxiang@cdjrlc.com/
> [3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxiang@cdjrlc.com/
> [4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxiang@cdjrlc.com/
>
> IMHO, these patches should have been in a single, consolidated patch, since
> these strip duplicate (hence redundant) word (single logical change).

They go to different maintainers, so perhaps each one would prefer to get
their own patches?  There was a trivial tree, but it is apparently not
very active.

It would indeed be good to indicate how the problems were found.  That
could suggest whether the problem has been addressed comprehensively, or
whether just some random issues have been detected.

julia

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22 13:46               ` Julia Lawall
  0 siblings, 0 replies; 26+ messages in thread
From: Julia Lawall @ 2022-06-22 13:46 UTC (permalink / raw)
  To: Bagas Sanjaya
  Cc: Julia Lawall, Shahab Vahedi, Jilin Yuan, vgupta, rdunlap,
	linux-snps-arc, linux-kernel



On Wed, 22 Jun 2022, Bagas Sanjaya wrote:

> On 6/22/22 16:38, Julia Lawall wrote:
> >>> So code that is fine will have typos forever?  Fixing typos in comments
> >>> doesn't break git blame for the following code.  And typos in comments
> >>> give a bad impression about the state of the code in general.
> >>
> >> Of course not! Documentation is as important as the code, if not even more.
> >> However, fixing typos to increase your commit counts to a reputable project
> >> is not fine either. For instance, many of these proposed fixes are targeting
> >> one single typo at a time. Couldn't they just be sent altogether!?!
> >
> > I have the impression that the person is just trying to figure out the
> > patch submission process.  For example, the subject lines are not
> > formatter in the standard way (I sent the person a private email about
> > that).  Perhaps just let him know about how you would rather have received
> > the patches.
>
> In recent times I had seen many typofix patches sent to LKML. You can see most
> of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches
> have been merged, though.
>
> What I say as starter thread is "ideal" scenario as described in
> Documentation/process/2.Process.rst; that is we prefer to see these minor
> fixes as part of real patches work (say refactoring), rather than just being
> trivial patches.
>
> But what most reviewers here missed is how these typos are found? I guess
> these can be from codespell or some other tools, or even manual review,
> then send the fixes en mass.
>
> Take a look at "fix typo in a comment" aka "delete redundant word" patches
> at [1], [2], [3]. and [4].
>
> [1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxiang@cdjrlc.com/
> [2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxiang@cdjrlc.com/
> [3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxiang@cdjrlc.com/
> [4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxiang@cdjrlc.com/
>
> IMHO, these patches should have been in a single, consolidated patch, since
> these strip duplicate (hence redundant) word (single logical change).

They go to different maintainers, so perhaps each one would prefer to get
their own patches?  There was a trivial tree, but it is apparently not
very active.

It would indeed be good to indicate how the problems were found.  That
could suggest whether the problem has been addressed comprehensively, or
whether just some random issues have been detected.

julia

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22 13:46               ` Julia Lawall
@ 2022-06-22 14:10                 ` Conor.Dooley
  -1 siblings, 0 replies; 26+ messages in thread
From: Conor.Dooley @ 2022-06-22 14:10 UTC (permalink / raw)
  To: julia.lawall, bagasdotme
  Cc: Shahab.Vahedi, yuanjilin, vgupta, rdunlap, linux-snps-arc, linux-kernel



On 22/06/2022 14:46, Julia Lawall wrote:
> 
> 
> On Wed, 22 Jun 2022, Bagas Sanjaya wrote:
> 
>> On 6/22/22 16:38, Julia Lawall wrote:
>>>>> So code that is fine will have typos forever?  Fixing typos in comments
>>>>> doesn't break git blame for the following code.  And typos in comments
>>>>> give a bad impression about the state of the code in general.
>>>>
>>>> Of course not! Documentation is as important as the code, if not even more.
>>>> However, fixing typos to increase your commit counts to a reputable project
>>>> is not fine either. For instance, many of these proposed fixes are targeting
>>>> one single typo at a time. Couldn't they just be sent altogether!?!
>>>
>>> I have the impression that the person is just trying to figure out the
>>> patch submission process.  For example, the subject lines are not
>>> formatter in the standard way (I sent the person a private email about
>>> that).  Perhaps just let him know about how you would rather have received
>>> the patches.
>>
>> In recent times I had seen many typofix patches sent to LKML. You can see most
>> of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches
>> have been merged, though.
>>
>> What I say as starter thread is "ideal" scenario as described in
>> Documentation/process/2.Process.rst; that is we prefer to see these minor
>> fixes as part of real patches work (say refactoring), rather than just being
>> trivial patches.
>>
>> But what most reviewers here missed is how these typos are found? I guess
>> these can be from codespell or some other tools, or even manual review,
>> then send the fixes en mass.
>>
>> Take a look at "fix typo in a comment" aka "delete redundant word" patches
>> at [1], [2], [3]. and [4].
>>
>> [1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxiang@cdjrlc.com/
>> [2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxiang@cdjrlc.com/
>> [3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxiang@cdjrlc.com/
>> [4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxiang@cdjrlc.com/
>>
>> IMHO, these patches should have been in a single, consolidated patch, since
>> these strip duplicate (hence redundant) word (single logical change).
> 
> They go to different maintainers, so perhaps each one would prefer to get
> their own patches?  There was a trivial tree, but it is apparently not
> very active.
> 
> It would indeed be good to indicate how the problems were found.  That
> could suggest whether the problem has been addressed comprehensively, or
> whether just some random issues have been detected.

It would be interesting to see what tool it is, because there appear to be
a bunch of false positives (although maybe that is on the user to read and
understand the tool's output)

Thanks,
Conor.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-22 14:10                 ` Conor.Dooley
  0 siblings, 0 replies; 26+ messages in thread
From: Conor.Dooley @ 2022-06-22 14:10 UTC (permalink / raw)
  To: julia.lawall, bagasdotme
  Cc: Shahab.Vahedi, yuanjilin, vgupta, rdunlap, linux-snps-arc, linux-kernel



On 22/06/2022 14:46, Julia Lawall wrote:
> 
> 
> On Wed, 22 Jun 2022, Bagas Sanjaya wrote:
> 
>> On 6/22/22 16:38, Julia Lawall wrote:
>>>>> So code that is fine will have typos forever?  Fixing typos in comments
>>>>> doesn't break git blame for the following code.  And typos in comments
>>>>> give a bad impression about the state of the code in general.
>>>>
>>>> Of course not! Documentation is as important as the code, if not even more.
>>>> However, fixing typos to increase your commit counts to a reputable project
>>>> is not fine either. For instance, many of these proposed fixes are targeting
>>>> one single typo at a time. Couldn't they just be sent altogether!?!
>>>
>>> I have the impression that the person is just trying to figure out the
>>> patch submission process.  For example, the subject lines are not
>>> formatter in the standard way (I sent the person a private email about
>>> that).  Perhaps just let him know about how you would rather have received
>>> the patches.
>>
>> In recent times I had seen many typofix patches sent to LKML. You can see most
>> of them by querying `s:"fix typo"` on lore.kernel.org. Some of these patches
>> have been merged, though.
>>
>> What I say as starter thread is "ideal" scenario as described in
>> Documentation/process/2.Process.rst; that is we prefer to see these minor
>> fixes as part of real patches work (say refactoring), rather than just being
>> trivial patches.
>>
>> But what most reviewers here missed is how these typos are found? I guess
>> these can be from codespell or some other tools, or even manual review,
>> then send the fixes en mass.
>>
>> Take a look at "fix typo in a comment" aka "delete redundant word" patches
>> at [1], [2], [3]. and [4].
>>
>> [1]: https://lore.kernel.org/lkml/20220618132659.17100-1-wangxiang@cdjrlc.com/
>> [2]: https://lore.kernel.org/lkml/20220618130349.11507-1-wangxiang@cdjrlc.com/
>> [3]: https://lore.kernel.org/lkml/20220616163830.11366-1-wangxiang@cdjrlc.com/
>> [4]: https://lore.kernel.org/lkml/20220606123419.29109-1-wangxiang@cdjrlc.com/
>>
>> IMHO, these patches should have been in a single, consolidated patch, since
>> these strip duplicate (hence redundant) word (single logical change).
> 
> They go to different maintainers, so perhaps each one would prefer to get
> their own patches?  There was a trivial tree, but it is apparently not
> very active.
> 
> It would indeed be good to indicate how the problems were found.  That
> could suggest whether the problem has been addressed comprehensively, or
> whether just some random issues have been detected.

It would be interesting to see what tool it is, because there appear to be
a bunch of false positives (although maybe that is on the user to read and
understand the tool's output)

Thanks,
Conor.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-22  8:30   ` Bagas Sanjaya
@ 2022-06-23  2:50     ` Vineet Gupta
  -1 siblings, 0 replies; 26+ messages in thread
From: Vineet Gupta @ 2022-06-23  2:50 UTC (permalink / raw)
  To: Bagas Sanjaya, Jilin Yuan
  Cc: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel



On 6/22/22 01:30, Bagas Sanjaya wrote:
>> - * If the U-mapping is not congruent to to K-mapping, former needs flushing.
>> + * If the U-mapping is not congruent to K-mapping, former needs flushing.
>>    */
>>   void flush_dcache_page(struct page *page)
>>   {
> The patch is OK, but its subject is wrong.

Right.

> The patch above isn't fixing any syntax errors, but rather minor cleanup.
> The subject should have been "Remove duplicate 'to' in the
> flush_dcache_page() comment".

I'd just say "ARC: mm: fix typos"

> I think that this kind of cleanup patches (typofixes) are best done
> as part of **actual** work on the code in question (for example
> refactoring or fixing build errors).

In an ideal world yes. But sometimes maintainer complain to break 
whitespacxe fixes and such into independent fix. Also as someone said 
later in the thread, for somebody just getting into kernel and figuring 
out patch submission etc this could be a perfect dry run and helps 
improve the code anyways.

-Vineet

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-23  2:50     ` Vineet Gupta
  0 siblings, 0 replies; 26+ messages in thread
From: Vineet Gupta @ 2022-06-23  2:50 UTC (permalink / raw)
  To: Bagas Sanjaya, Jilin Yuan
  Cc: vgupta, Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel



On 6/22/22 01:30, Bagas Sanjaya wrote:
>> - * If the U-mapping is not congruent to to K-mapping, former needs flushing.
>> + * If the U-mapping is not congruent to K-mapping, former needs flushing.
>>    */
>>   void flush_dcache_page(struct page *page)
>>   {
> The patch is OK, but its subject is wrong.

Right.

> The patch above isn't fixing any syntax errors, but rather minor cleanup.
> The subject should have been "Remove duplicate 'to' in the
> flush_dcache_page() comment".

I'd just say "ARC: mm: fix typos"

> I think that this kind of cleanup patches (typofixes) are best done
> as part of **actual** work on the code in question (for example
> refactoring or fixing build errors).

In an ideal world yes. But sometimes maintainer complain to break 
whitespacxe fixes and such into independent fix. Also as someone said 
later in the thread, for somebody just getting into kernel and figuring 
out patch submission etc this could be a perfect dry run and helps 
improve the code anyways.

-Vineet

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-23  2:50     ` Vineet Gupta
@ 2022-06-23  7:56       ` Bagas Sanjaya
  -1 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-23  7:56 UTC (permalink / raw)
  To: Vineet Gupta, Jilin Yuan
  Cc: Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/23/22 09:50, Vineet Gupta wrote:
>> The patch is OK, but its subject is wrong.
> 
> Right.
> 
>> The patch above isn't fixing any syntax errors, but rather minor cleanup.
>> The subject should have been "Remove duplicate 'to' in the
>> flush_dcache_page() comment".
> 
> I'd just say "ARC: mm: fix typos"
> 

OK.

> In an ideal world yes. But sometimes maintainer complain to break whitespacxe fixes and such into independent fix. Also as someone said later in the thread, for somebody just getting into kernel and figuring out patch submission etc this could be a perfect dry run and helps improve the code anyways.
> 

Seems like you missed the point that it's OK to have typofixes while
doing other real changes (like refactoring) in the same patch.

Quoting from [1]:

> My opinion is that trivial patches like this are fine as a starting
> point for new contributors, which is why I acked the previous patch from
> you guys. However, if we start getting two of these every week it just
> adds more maintenance burden than it's worth.

I tend to agree with the last sentence of above quote. Let's pretend that
I'm the tree maintainer. Besides reviewing real change patches, I get
flooded by these similar minor cleanup patches that I need to review.
Some (but not all) these patches have issues (say subject or description
error) that are repeated. Lazily speaking, I'd like to privately notice the
submitter about the situation, and I withhold these for now.

Thanks.

[1]: https://lore.kernel.org/lkml/0308c92a-0e10-35a4-928b-8f715a7bae44@linbit.com/

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-23  7:56       ` Bagas Sanjaya
  0 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-23  7:56 UTC (permalink / raw)
  To: Vineet Gupta, Jilin Yuan
  Cc: Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/23/22 09:50, Vineet Gupta wrote:
>> The patch is OK, but its subject is wrong.
> 
> Right.
> 
>> The patch above isn't fixing any syntax errors, but rather minor cleanup.
>> The subject should have been "Remove duplicate 'to' in the
>> flush_dcache_page() comment".
> 
> I'd just say "ARC: mm: fix typos"
> 

OK.

> In an ideal world yes. But sometimes maintainer complain to break whitespacxe fixes and such into independent fix. Also as someone said later in the thread, for somebody just getting into kernel and figuring out patch submission etc this could be a perfect dry run and helps improve the code anyways.
> 

Seems like you missed the point that it's OK to have typofixes while
doing other real changes (like refactoring) in the same patch.

Quoting from [1]:

> My opinion is that trivial patches like this are fine as a starting
> point for new contributors, which is why I acked the previous patch from
> you guys. However, if we start getting two of these every week it just
> adds more maintenance burden than it's worth.

I tend to agree with the last sentence of above quote. Let's pretend that
I'm the tree maintainer. Besides reviewing real change patches, I get
flooded by these similar minor cleanup patches that I need to review.
Some (but not all) these patches have issues (say subject or description
error) that are repeated. Lazily speaking, I'd like to privately notice the
submitter about the situation, and I withhold these for now.

Thanks.

[1]: https://lore.kernel.org/lkml/0308c92a-0e10-35a4-928b-8f715a7bae44@linbit.com/

-- 
An old man doll... just what I always wanted! - Clara

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-23  7:56       ` Bagas Sanjaya
@ 2022-06-24  1:57         ` Vineet Gupta
  -1 siblings, 0 replies; 26+ messages in thread
From: Vineet Gupta @ 2022-06-24  1:57 UTC (permalink / raw)
  To: Bagas Sanjaya, Vineet Gupta, Jilin Yuan
  Cc: Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/23/22 00:56, Bagas Sanjaya wrote:
>> In an ideal world yes. But sometimes maintainer complain to break whitespacxe fixes and such into independent fix. Also as someone said later in the thread, for somebody just getting into kernel and figuring out patch submission etc this could be a perfect dry run and helps improve the code anyways.
>>
> Seems like you missed the point that it's OK to have typofixes while
> doing other real changes (like refactoring) in the same patch.

No I did not.

> Quoting from [1]:
>
>> My opinion is that trivial patches like this are fine as a starting
>> point for new contributors, which is why I acked the previous patch from
>> you guys. However, if we start getting two of these every week it just
>> adds more maintenance burden than it's worth.
> I tend to agree with the last sentence of above quote. Let's pretend that
> I'm the tree maintainer. Besides reviewing real change patches, I get
> flooded by these similar minor cleanup patches that I need to review.
> Some (but not all) these patches have issues (say subject or description
> error) that are repeated.

"Repeated" is the key - First time I'd politely tell them to DTRT but 
will just ignore if things continue.

> Lazily speaking, I'd like to privately notice the
> submitter about the situation, and I withhold these for now.

Funny that you say this: ever since this got posted I now see 3 patches 
for typo fixes :-)
But it is something in maintainers purview and for now i'm ok.

Thx,
-Vineet

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-24  1:57         ` Vineet Gupta
  0 siblings, 0 replies; 26+ messages in thread
From: Vineet Gupta @ 2022-06-24  1:57 UTC (permalink / raw)
  To: Bagas Sanjaya, Vineet Gupta, Jilin Yuan
  Cc: Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/23/22 00:56, Bagas Sanjaya wrote:
>> In an ideal world yes. But sometimes maintainer complain to break whitespacxe fixes and such into independent fix. Also as someone said later in the thread, for somebody just getting into kernel and figuring out patch submission etc this could be a perfect dry run and helps improve the code anyways.
>>
> Seems like you missed the point that it's OK to have typofixes while
> doing other real changes (like refactoring) in the same patch.

No I did not.

> Quoting from [1]:
>
>> My opinion is that trivial patches like this are fine as a starting
>> point for new contributors, which is why I acked the previous patch from
>> you guys. However, if we start getting two of these every week it just
>> adds more maintenance burden than it's worth.
> I tend to agree with the last sentence of above quote. Let's pretend that
> I'm the tree maintainer. Besides reviewing real change patches, I get
> flooded by these similar minor cleanup patches that I need to review.
> Some (but not all) these patches have issues (say subject or description
> error) that are repeated.

"Repeated" is the key - First time I'd politely tell them to DTRT but 
will just ignore if things continue.

> Lazily speaking, I'd like to privately notice the
> submitter about the situation, and I withhold these for now.

Funny that you say this: ever since this got posted I now see 3 patches 
for typo fixes :-)
But it is something in maintainers purview and for now i'm ok.

Thx,
-Vineet

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
  2022-06-24  1:57         ` Vineet Gupta
@ 2022-06-24  3:16           ` Bagas Sanjaya
  -1 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-24  3:16 UTC (permalink / raw)
  To: Vineet Gupta, Jilin Yuan
  Cc: Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/24/22 08:57, Vineet Gupta wrote:
> "Repeated" is the key - First time I'd politely tell them to DTRT but will just ignore if things continue.
> 
>> Lazily speaking, I'd like to privately notice the
>> submitter about the situation, and I withhold these for now.
> 
> Funny that you say this: ever since this got posted I now see 3 patches for typo fixes :-)
> But it is something in maintainers purview and for now i'm ok.
> 

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH] ARC:mm:Fix syntax errors in comments
@ 2022-06-24  3:16           ` Bagas Sanjaya
  0 siblings, 0 replies; 26+ messages in thread
From: Bagas Sanjaya @ 2022-06-24  3:16 UTC (permalink / raw)
  To: Vineet Gupta, Jilin Yuan
  Cc: Julia.Lawall, rdunlap, linux-snps-arc, linux-kernel

On 6/24/22 08:57, Vineet Gupta wrote:
> "Repeated" is the key - First time I'd politely tell them to DTRT but will just ignore if things continue.
> 
>> Lazily speaking, I'd like to privately notice the
>> submitter about the situation, and I withhold these for now.
> 
> Funny that you say this: ever since this got posted I now see 3 patches for typo fixes :-)
> But it is something in maintainers purview and for now i'm ok.
> 

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2022-06-24  3:20 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-22  8:04 [PATCH] ARC:mm:Fix syntax errors in comments Jilin Yuan
2022-06-22  8:04 ` Jilin Yuan
2022-06-22  8:30 ` Bagas Sanjaya
2022-06-22  8:30   ` Bagas Sanjaya
2022-06-22  8:42   ` Shahab Vahedi
2022-06-22  8:42     ` Shahab Vahedi
2022-06-22  9:16     ` Julia Lawall
2022-06-22  9:16       ` Julia Lawall
2022-06-22  9:25       ` Shahab Vahedi
2022-06-22  9:25         ` Shahab Vahedi
2022-06-22  9:38         ` Julia Lawall
2022-06-22  9:38           ` Julia Lawall
2022-06-22 13:20           ` Bagas Sanjaya
2022-06-22 13:20             ` Bagas Sanjaya
2022-06-22 13:46             ` Julia Lawall
2022-06-22 13:46               ` Julia Lawall
2022-06-22 14:10               ` Conor.Dooley
2022-06-22 14:10                 ` Conor.Dooley
2022-06-23  2:50   ` Vineet Gupta
2022-06-23  2:50     ` Vineet Gupta
2022-06-23  7:56     ` Bagas Sanjaya
2022-06-23  7:56       ` Bagas Sanjaya
2022-06-24  1:57       ` Vineet Gupta
2022-06-24  1:57         ` Vineet Gupta
2022-06-24  3:16         ` Bagas Sanjaya
2022-06-24  3:16           ` Bagas Sanjaya

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.