Re: [pchecks v1 4/4] percpu: Add preemption checks to __this_cpu ops

[Ingo Molnar <mingo@kernel.org>]

* Christoph Lameter <cl@linux.com> wrote:

> On Tue, 24 Sep 2013, Ingo Molnar wrote:
> 
> > > > > >
> > > > > > Your lack of cooperation is getting ridiculous!
> > > > >
> > > > > And this kind of insulting behavior is really discouraging 
> > > > > people to do work on the kernel.
> >
> > You can stop playing the victim card: you are not a newbie anymore by 
> > any definition, you've been hacking the Linux kernel for how long, 10+ 
> > years, writing hundreds of patches? People expect higher quality 
> > series from you and you need to learn to address criticism of your 
> > workflow as well.
> >
> > You won't find a _single_ mail in the last 15+ years of lkml where I 
> > reacted strongly to a newbie being dense or abusive. Newbies can make 
> > all sorts of mistakes, it's part of the learning process - but after 
> > 10 years you are not a newbie anymore...
> 
> This has nothing to do with newbieness but with general communication 
> behavior. I am not a full time kernel developer (nor would I want to be 
> because it seems to cause some sort of cabin fever) and need to take 
> time off my other duties in order to work on these patches. Time is 
> limited.
> 
> And then instead of thanks I get insults sprinkled with some paranoia.

Pointing out your lack of cooperation (such as repeatedly ignoring 
maintainer feedback) is not an "insult" - it's my duty as a maintainer to 
protect other submitters who do their homework and it's also my duty as a 
maintainer to keep crappy patches from entering the kernel. Resisting 
low-quality patches like yours and pointing out patch submission errors 
and inefficiencies is my job.

For example lets just take your latest submission from yesterday to see 
sloppiness in action:

63175   C Sep 24 Christoph Lamet ( 121) ┬─>[pchecks v2 1/2] Subject; percpu: Add raw_cpu_ops
63176   C Sep 24 Christoph Lamet ( 206) └─>[pchecks v2 2/2] percpu: Add preemption checks to __this_cpu ops
63178   C Sep 24 Christoph Lamet (  14) [pchecks v2 0/2] percpu v2: Implement Preemption checks for __this_cpu operatio

The 0/2 mail arrived before the 1/2 and 2/2 mails, because you did not use 
git-send-email threading options properly to thread them all together...

Furthermore, your first patch's subject line was mangled in a weird way, 
mentioning 'Subject;' twice:

  Subject: [pchecks v2 1/2] Subject; percpu: Add raw_cpu_ops

Patch submissions are expected to have such a coherent format:

63346   T Sep 25 Arnaldo Carvalh (  70) [GIT PULL 0/6] perf/urgent fixes
63347   T Sep 25 Arnaldo Carvalh (  37) ├─>[PATCH 1/6] perf kmem: Make it work again on non NUMA machines
63348   T Sep 25 Arnaldo Carvalh (  31) ├─>[PATCH 2/6] perf trace: Add mmap2 handler
63349   T Sep 25 Arnaldo Carvalh ( 218) ├─>[PATCH 3/6] perf probe: Fix probing symbols with optimization suffix
63350   T Sep 25 Arnaldo Carvalh (  27) ├─>[PATCH 4/6] perf tools: Explicitly add libdl dependency
63351   T Sep 25 Arnaldo Carvalh (  37) ├─>[PATCH 5/6] perf machine: Fix path unpopulated in machine__create_modules()
63352   T Sep 25 Arnaldo Carvalh (  56) └─>[PATCH 6/6] perf symbols: Demangle cloned functions

It's not rocket science - and in fact it takes less time to submit patches 
properly and consistently.

All that can be ignored if the submitter is a newbie who is struggling 
with his first few submissions - but you with 10+ years of experience and 
hundreds of patches track record are held to a higher standard.

Such kind of trivial quality problems does not give me any confidence at 
all to consider your patches for inclusion - which modify the core kernel 
after all. There are tons of part-time developers who get their 
submissions right.

If you have limited time to contribute I'd suggest you work on each 
submission a bit more before sending them, to make sure it has the 
expected quality, to make sure you've addressed all review feedback, etc. 
- this will waste less time of everyone involved and will generally result 
in fewer complaints as well.

Thanks,

	Ingo