public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox