* Christoph Lameter <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
