All of lore.kernel.org
 help / color / mirror / Atom feed
From: nick <xerofoify@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>, Michal Hocko <mhocko@suse.cz>,
	akpm@linux-foundation.org, mgorman@suse.de,
	n-horiguchi@ah.jp.nec.com, sasha.levin@oracle.com,
	Yalin.Wang@sonymobile.com, jmarchan@redhat.com,
	kirill@shutemov.name, rientjes@google.com, vbabka@suse.cz,
	aneesh.kumar@linux.vnet.ibm.com, ebru.akagunduz@gmail.com,
	hannes@cmpxchg.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm:Make the function zap_huge_pmd bool
Date: Fri, 03 Jul 2015 10:54:07 -0400	[thread overview]
Message-ID: <5596A20F.6010509@gmail.com> (raw)
In-Reply-To: <20150703144635.GE9456@thunk.org>



On 2015-07-03 10:46 AM, Theodore Ts'o wrote:
> On Thu, Jul 02, 2015 at 12:08:36PM -0400, nick wrote:
>> I looked into that patch further and would were correct it was wrong.
>> However here is a bug fix for the drm driver code that somebody else
>> stated was right but haven gotten a reply to from the maintainer and
>> have tried resending.
> 
> Hi Nick,
> 
> Don't bother sending more low-value patches like this; they don't
> impress me.  Send me a patch that fixes a deep bug, where you can
> demonstrate that you understand the underlying design of the code, can
> point out a flaw, and then explain why your patch is an improvement,
> and documents how you tested it.  Or do something beyond changing
> return values or return types, and optimize some performance-critical
> part of the kernel, and in the commit description, explain why it
> improves things, how you measured the performance improvement, and why
> this is applicable in a real-life situation.
> 
> Even a broken clock can be right twice a day, and the fact that it is
> possible that you can author a correct patch isn't all that
> impressive.  You need to understand deep understanding of the code you
> are modifying, and or else it's not worth my time to go through a
> large number of low-value patches that don't really improve the code
> base much, when the risk that you have accidentally introduced a bug
> is high given that (a) you've demonstrated an inability to explain
> some of your patches, and (b) in many cases, you have no fear about
> sending patches that you can't personally test.  These two
> shortcomings in combination are fatal.
> 
> If you can demonstrate that you can become a thoughtful and careful
> coder, I would be most pleased to argue to Greg K-H that you have
> turned over a new leaf.  To date, however, you have not demonstrated
> any of the above, and you've made me regret that I've tried to waste
> time looking at your patches that you've sent me in the hopes of
> convincing me that you've really changed --- when it's clear you
> haven't.  I do hope that, one day, you will be able to be a good
> coder.  But that day is clearly not today.
> 
> Best regards,
> 
> 					- Ted
> 
Did you even look at the other patches I send you. Here is a bug fix for the gma500 driver code
that someone else stated is right but I don't have the hardware so it's difficult to test.
Nick

  reply	other threads:[~2015-07-03 14:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-01 18:27 [PATCH] mm:Make the function zap_huge_pmd bool Nicholas Krause
2015-07-02  7:26 ` Michal Hocko
2015-07-02  7:26   ` Michal Hocko
2015-07-02 16:03   ` Theodore Ts'o
2015-07-02 16:03     ` Theodore Ts'o
2015-07-02 16:08     ` nick
2015-07-02 17:07       ` nick
2015-07-03 14:46       ` Theodore Ts'o
2015-07-03 14:46         ` Theodore Ts'o
2015-07-03 14:54         ` nick [this message]
2015-07-03 15:01           ` Michal Hocko
2015-07-03 15:01             ` Michal Hocko
2015-07-03 15:03             ` nick
2015-07-03 16:49               ` Theodore Ts'o
2015-07-03 16:49                 ` Theodore Ts'o
2015-07-03 16:52                 ` nick
2015-07-03 18:45                   ` Theodore Ts'o
2015-07-03 18:45                     ` Theodore Ts'o
2015-07-03 19:49                     ` nick
2015-07-03 20:13                     ` Mel Gorman
2015-07-03 20:13                       ` Mel Gorman
2015-07-03 20:47                       ` nick

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=5596A20F.6010509@gmail.com \
    --to=xerofoify@gmail.com \
    --cc=Yalin.Wang@sonymobile.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=ebru.akagunduz@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=jmarchan@redhat.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=rientjes@google.com \
    --cc=sasha.levin@oracle.com \
    --cc=tytso@mit.edu \
    --cc=vbabka@suse.cz \
    /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.