From: Jaswinder Singh Rajput <jaswinder@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Yinghai Lu <yinghai@kernel.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches
Date: Mon, 06 Jul 2009 03:39:52 +0530 [thread overview]
Message-ID: <1246831792.2398.37.camel@ht.satnam> (raw)
In-Reply-To: <20090705182151.GA7668@elte.hu>
On Sun, 2009-07-05 at 20:21 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
>
> - You managed to put _3_ separate bugs into these 'trivial'
> cleanups. That is not acceptable. If you cannot make trivial
> patches be truly trivial, you should not be doing them really.
>
Where is the list of _3_ bugs. If there was bugs you should report to
me. If there are bugs show to me, why are you hiding the details.
So it is your mistake.
> - i had to remove/undo/fix some bogus 'fixes' you did in those
> patches where you just blindly followed checkpatch instead of
> thinking about it for a minute. We dont want checkpatch warriors
> - we want people with taste who use it as a tool to keep their
> new patches tidy, or who use it as a tool to aid cleanups.
>
If there was bogus 'fixes', then you should ignore that patch. Or let me
know I will fix that.
So it is your mistake.
> - i had to complete the patches and do all the cleanups you missed
> - sometimes on the next time to a change you did. You apparently
> only checked checkpatch output - you didnt even look at all the
> files for how it all looks like and whether there are other
> things in those files that checkpatch missed. You made the files
> 'checkpatch clean' - but you didnt actually look at whether the
> files got cleaned up for good really. You left a half-done
> jumbled mess behind you with files that still had inconsistent
> looking style in them. Check the deltas of the patches i
> committed versus the ones you sent to see the countless cases you
> missed. And you cannot even claim to have done the 'trivial'
> ones safely - because you did it in a buggy way and because the
> final cleanups i did are all trivial too and can be validated.
>
If you want more cleanup, you should do in separate patch, why you keep
on changing my patch.
This is a never ending task I can do further clean-ups on your patches
also.
So again it is your mistake.
> - i had to double check each commit on the assembly level to prove
> that the patches are true cleanups. The new commit logs, size
> checks, md5 sums are proof of that due diligence process. You
> obviously didnt do any of that - you'd have noticed the bugs you
> have put in had you done that.
>
Why you did this, you never told me to do so.
So again it is your mistake.
> - i had to edit _all_ your changelogs. Again. You _still_ dont
> think about your changelogs, they still suck 90% of the time.
>
Again this is never ending task, even Linus and Andrew can further
change changelog made by you, it is a personnel flavor.
> All things considered it took me 6 hours to fix up and complete your
> 'trivial' patches into which you have put only 3 hours of work:
>
> - your buggy and incomplete cleanups did:
>
> 9 files changed, 263 insertions(+), 329 deletions(-)
>
> - the proper, fixed, rounded up, checked, validated and working
> cleanups i committed with 6 extra hours of work:
>
> 9 files changed, 868 insertions(+), 862 deletions(-)
>
> The MTRR code is a highly critical piece of x86 code and i had to
> check assembly dumps manually and compared them to make sure the
> changes dont introduce subtle regressions.
>
If you want to do it, you should do in separate patches.
It is again your mistake.
> The fact is, there is no other way to establish the trust level of
> trivial cleanups but to invest this depth of review and this level
> of testing and checking. I cannot just review until i find the first
> bug or problem and bounce it back to you as a review failure - i
> cannot know whether i can trust your next version of the patch and i
> cannot check the same trivial cleanups again and again as a machine,
> until you manage to submit the correct one.
>
> So i've tested the trustworthyness of your changes for a final time
> and you failed this test.
>
You never told me to test in this manner.
> I still committed it all under your name because i kept a fair
> amount of your changes so it's all v2 versions of your original
> patches - and per kernel convention i noted it in the changelog that
> i modified it further (and i didnt want to create 9 more commits,
> especially as some of your patches were broken so not bisection
> safe) - but this was the last time i went through such an effort
> with your patches.
>
Why you committed under my name, I do not need your such help if you
again shout at me.
If there was issue then you should ignore my patches and start from
scratch.
This is again your mistake.
> As i warned you _repeatedly_ in the past that you should insert a
> lot more effort into patches before sending any patches and before
> sending any pull request. Other x86 maintainers warned you about
> that too. You seem to prefer five patches a day (a few of which are
> inevitably broken) instead of one good patch every five days.
>
> This low level of patch quality just does not scale for maintainers
> of a busy tree which has more than a hundred contributors in every
> cycle. If i cannot trust a contributor i cannot apply such patches
> directly.
>
> All in one, you were making the same kinds of mistakes again and
> again, over a many month time-span, and you are causing a
> considerable amount of maintainer overhead that is just not
> sustainable really.
>
If I can spend 10-16 hours in a day and no one is paying to me, I am
spending from my pocket. And I send 5 patches in a day.
For you it will not take more than 5-10 minutes to review my 5 patches.
This is your job, and your are getting salary for it.
You should be thankful to me instead of blaming me.
So again it is your fault.
> So this simply does not work in this form. I can work with pretty
> much anyone, but there's a final limit to the energy i can invest
> into this. Please find some other Linux maintainer who can work with
> you and who is willing to apply your patches. If you want to work on
> x86 bits please find an x86 developer or maintainer who is willing
> to apply your patches or who is willing to give you Reviewed-by tags
> before sending them to me.
>
So you are blaming me for your faults.
I am contributing to open-source from my pocket, because I thought that
open-source people are open-heart (big heart), but now it seems I was
wrong. You are having very little heart and very low tolerance.
Thanks,
--
JSR
next prev parent reply other threads:[~2009-07-05 22:19 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 11:36 [PATCH] vt: add an event interface Alan Cox
2009-07-03 6:45 ` Ingo Molnar
2009-07-03 9:08 ` Alan Cox
2009-07-03 9:16 ` Ingo Molnar
2009-07-03 9:44 ` Alan Cox
2009-07-03 9:54 ` Ingo Molnar
2009-07-03 10:06 ` Alan Cox
2009-07-03 10:22 ` Ingo Molnar
2009-07-03 10:44 ` Alan Cox
2009-07-03 13:17 ` Ingo Molnar
2009-07-03 13:37 ` Alan Cox
2009-07-03 14:47 ` Ingo Molnar
2009-07-03 15:02 ` Alan Cox
2009-07-03 15:42 ` Ingo Molnar
2009-07-03 15:48 ` Ingo Molnar
2009-07-03 16:11 ` Alan Cox
2009-07-03 16:24 ` Ingo Molnar
2009-07-03 18:29 ` Alan Cox
2009-07-03 18:41 ` Ingo Molnar
2009-07-03 15:57 ` Ingo Molnar
2009-07-03 15:58 ` Ingo Molnar
2009-07-03 16:26 ` Alan Cox
2009-07-03 16:33 ` Ingo Molnar
2009-07-03 16:42 ` Ingo Molnar
2009-07-03 22:17 ` Jaswinder Singh Rajput
2009-07-04 2:18 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Jaswinder Singh Rajput
2009-07-04 2:20 ` [PATCH 1/9 -tip] x86: mtrr/amd.c fix trivial style problems Jaswinder Singh Rajput
2009-07-04 2:20 ` [PATCH 2/9 -tip] x86: mtrr/centaur.c fix " Jaswinder Singh Rajput
2009-07-04 2:21 ` [PATCH 3/9 -tip] x86: mtrr/cleanup.c fix trivial " Jaswinder Singh Rajput
2009-07-04 2:22 ` [PATCH 4/9 -tip] x86: mtrr/cyrix.c " Jaswinder Singh Rajput
2009-07-04 2:23 ` [PATCH 5/9 -tip] x86: mtrr/generic.c fix " Jaswinder Singh Rajput
2009-07-04 2:23 ` [PATCH 6/9 -tip] x86: mtrr/if.c fix trivial " Jaswinder Singh Rajput
2009-07-04 2:24 ` [PATCH 7/9 -tip] x86: mtrr/mtrr.h " Jaswinder Singh Rajput
2009-07-04 2:24 ` [PATCH 8/9 -tip] x86: mtrr/state.c " Jaswinder Singh Rajput
2009-07-04 2:26 ` [PATCH 9/9 -tip] x86: mtrr/main.c fix " Jaswinder Singh Rajput
2009-07-05 18:21 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Ingo Molnar
2009-07-05 22:09 ` Jaswinder Singh Rajput [this message]
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/amd.c: tip-bot for Jaswinder Singh Rajput
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/centaur.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c tip-bot for Jaswinder Singh Rajput
2009-07-04 21:12 ` Yinghai Lu
2009-07-05 0:27 ` Ingo Molnar
2009-07-05 6:02 ` Jaswinder Singh Rajput
2009-07-05 11:59 ` Pekka Enberg
2009-07-05 13:19 ` Jaswinder Singh Rajput
2009-07-05 20:11 ` Thomas Gleixner
2009-07-05 22:16 ` Jaswinder Singh Rajput
2009-07-05 18:04 ` Ingo Molnar
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cyrix.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/generic.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/if.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/mtrr.h tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/state.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/main.c tip-bot for Jaswinder Singh Rajput
2009-07-05 7:57 ` [tip:x86/cleanups] x86: Further clean up of mtrr/generic.c tip-bot for Ingo Molnar
2009-07-03 16:10 ` [PATCH] vt: add an event interface Ingo Molnar
2009-07-03 18:24 ` Alan Cox
2009-07-21 16:23 ` Lennart Poettering
2009-07-21 16:32 ` Alan Cox
2009-07-22 11:14 ` Lennart Poettering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1246831792.2398.37.camel@ht.satnam \
--to=jaswinder@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.