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

[Christoph Lameter]

On Wed, 25 Sep 2013, Ingo Molnar wrote:

> > 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.

Thats paranoia. No lack of cooperation. Feedback to patches during
development is normal until they reach proper maturity for merging. Thats
why these things are usually versioned.

> 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...

"quilt mail" was used for those which provides proper threading AFAICT.
The headers look fine here without the additional "subject: stuff". Wonder
why the 0/2 did not get put the right way.

> 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.

Certainly I am trying to address all the issues.