Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1176631 > unrolled thread

Re: [PATCH] mm:Make the function zap_huge_pmd bool

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] mm:Make the function zap_huge_pmd bool Theodore Ts'o <tytso@mit.edu> - 2015-07-03 16:50 +0200
    Re: [PATCH] mm:Make the function zap_huge_pmd bool Michal Hocko <mhocko@suse.cz> - 2015-07-03 17:10 +0200
      Re: [PATCH] mm:Make the function zap_huge_pmd bool Theodore Ts'o <tytso@mit.edu> - 2015-07-03 19:00 +0200

#1176631 — Re: [PATCH] mm:Make the function zap_huge_pmd bool

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

[toc] | [next] | [standalone]

#1176647

On Fri 03-07-15 10:54:07, nick wrote:
[...]
> 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.

This is really annoying. Please stop it! Ted is not maintainer of the
code you are trying to patch. There is absolutely no reason to try to
persuate him or try to push it through him. Go and try to "sell" your
patch to the maintainers of the said code.

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

[toc] | [prev] | [next] | [standalone]

#1176723

On Fri, Jul 03, 2015 at 11:03:11AM -0400, nick wrote:
> 
> The reason I am doing this is Ted is trying to find a bug that I
> fixed in order to prove to Greg Kroah Hartman I have
> changed. Otherwise I would be pushing this through the drm
> maintainer(s).

I am trying to determine if you have changed.  Your comment justifying
your lack of testing because "it's hard to test" is ample evidence
that you have *not* changed.

Simply coming up with a commit that happens to be correct is a
necessary, but not sufficient condition.  Especially when you feel
that you need to send dozens of low-value patches and hope that one of
them is correct, and then use that as "proof".  It's the attitude
which is problem, not whether or not you can manage to come up with a
correct patch.

I've described to you what you need to do in order to demonstrate that
you have the attitude and inclinations in order to be a kernel
developer that a maintainer can trust as being capable of authoring a
patch that doesn't create more problems than whatever benefits it
might have.  I respectfully ask that you try to work on that, and stop
bothering me (and everyone else).

Best regards,

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web