lkml.org 
[lkml]   [2009]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches
From
Date
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



\
 
 \ /
  Last update: 2009-07-06 00:23    [W:0.080 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site