Message-Id: <1246831792.2398.37.camel@ht.satnam>
Date:	Mon, 06 Jul 2009 03:39:52 +0530
From:	Jaswinder Singh Rajput <jaswinder@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches

On Sun, 2009-07-05 at 20:21 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@...nel.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

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

Powered by blists - more mailing lists