[PATCH] xen/rangeset: fix typo in comment

[PATCH] xen/rangeset: fix typo in comment

[Frediano Ziglio]

Fixes: fc41b5c1fdbe ("Extend the range abstraction"...)
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
---
 xen/common/rangeset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index b9e8912fb1..0e3b9acd35 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -38,7 +38,7 @@ struct rangeset {
 };
 
 /*****************************
- * Private range functions hide the underlying linked-list implemnetation.
+ * Private range functions hide the underlying linked-list implementation.
  */
 
 /* Find highest range lower than or containing s. NULL if no such range. */
-- 
2.43.0

Re: [PATCH] xen/rangeset: fix typo in comment

[Roger Pau Monné]

On Mon, Jul 28, 2025 at 01:50:33PM +0100, Frediano Ziglio wrote:
> Fixes: fc41b5c1fdbe ("Extend the range abstraction"...)
> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.

Re: [PATCH] xen/rangeset: fix typo in comment

[Jan Beulich]

On 28.07.2025 17:25, Roger Pau Monné wrote:
> On Mon, Jul 28, 2025 at 01:50:33PM +0100, Frediano Ziglio wrote:
>> Fixes: fc41b5c1fdbe ("Extend the range abstraction"...)
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> 
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Just to mention: I committed this as is with Roger's ack, but I don't think
a Fixes: tag is really appropriate here (I'm certainly not intending to
pick this up for backporting). Even further I question a patch changing the
spelling of a single word in a comment: It not only took you time to make
and send the patch, it also took people time to look at it, Roger to send
an ack, me to commit it, and now CI will put extra effort into testing it
in isolation via the build-each-commit job. That's way too much resource use
imo to justify the extremely minor effect. Such spelling mistakes are imo
best corrected when touching adjacent code anyway.

Jan

Re: [PATCH] xen/rangeset: fix typo in comment

[Frediano Ziglio]

On Tue, Jul 29, 2025 at 10:34 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 28.07.2025 17:25, Roger Pau Monné wrote:
> > On Mon, Jul 28, 2025 at 01:50:33PM +0100, Frediano Ziglio wrote:
> >> Fixes: fc41b5c1fdbe ("Extend the range abstraction"...)
> >> Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
> >
> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>
> Just to mention: I committed this as is with Roger's ack, but I don't think
> a Fixes: tag is really appropriate here (I'm certainly not intending to
> pick this up for backporting). Even further I question a patch changing the
> spelling of a single word in a comment: It not only took you time to make
> and send the patch, it also took people time to look at it, Roger to send
> an ack, me to commit it, and now CI will put extra effort into testing it
> in isolation via the build-each-commit job. That's way too much resource use
> imo to justify the extremely minor effect. Such spelling mistakes are imo
> best corrected when touching adjacent code anyway.
>
> Jan

Hi,
  I didn't know there was an automatism with the "Fixes:" tag.

I found the comment about the effort a bit harsh. In many different
open source projects this would be against the code of conduct.
Usually an open source project should promote contributions. This
seems not the case in Xen. A different phrasing would have been
better.

Other projects have separate handling for trivial patches. For
instance Qemu has some "TRIVIAL" marking, this will help batching
small changes like this; also the trivial changes have different
reviewers.
If the issue is CI resources we can talk about. For instance multiple
runners can be added, I have a runner too that helps when I compile my
branches. Suggesting other users to do that could relieve main
runners. Another option would be having the possibility to avoid
having to compile commits like this. Disabling the need to have every
commit compiled could be an option.

About the commits separation I prefer (and I'm not the only one) to
separate hunks and changes by purpose. Fixing typos is a different
purpose than other changes.

Regards,
  Frediano