Re: [PATCH 2/4] perf: fix common misspellings

From: Ingo Molnar
Date: Tue Mar 22 2011 - 07:44:28 EST



* Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> wrote:

> Hi Ingo,
>
> [ CC'ing Randy Dunlap and Jason Wessel ]
>
> On Tue, Mar 22, 2011 at 07:37, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Lucas De Marchi <lucas.de.marchi@xxxxxxxxx> wrote:
> >
> >> They were generated by 'codespell' and then manually reviewed.
> >>
> >> Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx>
> >> ---
> >>  arch/mips/kernel/perf_event_mipsxx.c |    2 +-
> >>  arch/powerpc/kernel/perf_event.c     |    2 +-
> >>  arch/sparc/kernel/perf_event.c       |    2 +-
> >>  arch/x86/kernel/cpu/perf_event.c     |    2 +-
> >>  arch/x86/kernel/cpu/perf_event_p4.c  |    8 ++++----
> >>  include/linux/perf_event.h           |    2 +-
> >>  tools/perf/util/string.c             |    2 +-
> >>  7 files changed, 10 insertions(+), 10 deletions(-)
> >
> > Hm, half of these do not apply anymore.
> >
> > Since they are auto-generated, mind sending one large spelling fixes patch to
> > Linus (for the whole kernel), at the end of the merge window, instead of these
> > zillions of small commits which just clutter the patchflow? That makes it a
> > heck of a lot easier to verify and handle for everyone involved.
>
> I agree with you, but last time I tried a large patch for fixing this
> I've been told to split the patches for each maintainer
> (http://kerneltrap.org/mailarchive/linux-kernel/2010/9/7/4616618). As
> you noticed it's a pain to apply them and it's even more for splitting
> in a per maintainer basis since it touches a lot of files.
>
> Randy, Jason: as you see maybe the split approach was not a good one.
>
> I'am all for applying this once, as Ingo said.

Well, ultimately it's up to Linus (i've Cc:-ed him).

For such pure spelling fixes i think what matters most is the timing, so that
it impacts outstanding trees in the smallest possible way. For that the best
timing would right before -rc1 - i.e. this week - as that is the moment when
the outstanding queues are the shortest.

Could you send the diffstat of the big, combined patch - how large is it total?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/