[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140723120748.5ef6e1b5@gandalf.local.home>
Date: Wed, 23 Jul 2014 12:07:48 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Nick Krause <xerofoify@...il.com>
Cc: Levente Kurusa <lkurusa@...hat.com>,
Tony Luck <tony.luck@...il.com>,
Bjørn Mork <bjorn@...k.no>,
Doug Thompson <dougthompson@...ssion.com>,
Borislav Petkov <bp@...en8.de>,
"m.chehab@...sung.com" <m.chehab@...sung.com>,
Linux Edac Mailing List <linux-edac@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] edac: Remove fixmes in e7xxx_edac.c
On Wed, 23 Jul 2014 11:35:21 -0400
Nick Krause <xerofoify@...il.com> wrote:
> Steve, I have make a few mistakes. That doesn't give you the right to
> put me under a waste of time yet.
Nobody is upset at you for making a few mistakes. But ignoring advice
from people is something quite different, and that is what tends to
piss people off.
You were told time and time again to stop this fixme craze because you
obviously didn't know the details of what you were fixing, but you
continued to care on. The issue is with these patches that you probably
caught a maintainer off guard, and they just accepted it thinking you
had some clue to the code you were fixing. Thus, not only are you
removing crucial comments about areas of code that needs more
attention, you end up making things worse. Your actions are dangerous to
the kernel and the fact you ignoring everyone telling you to stop it,
makes you dangerous to the kernel. That gives me the right to put you
under the "waste of time" folder.
Now it may seem that I'm being rather harsh to you, and I may be. The
Linux kernel is a serious project and it can not afford having to deal
with those that do not listen.
That said...
I see you stated in another email:
"Very well then I guess the community wants me to listen better to the
maintainers and not do stupid things"
Finally, you are listening.
You obviously are very enthusiastic, and I would like you not to waste
your own time and energy trying to help in a not so helpful way. If you
really want to help the Linux community, here's what you do.
Find a single area to focus on. Not a key word throughout the kernel.
Look at the USB stack, or find some driver in staging that is for some
really cheap hardware that you can afford. And get it cleaned up and
working nicely. Start simple. Try to understand that area completely.
Remember, nobody understand every aspect of the kernel. All the main
kernel developers are experts in select parts. I wouldn't even try
fixing "fixmes" in parts of the kernel that I'm unfamiliar with.
Find a part of the kernel, and learn every aspect of that part inside
and out. Study the code. Boot the kernel. Make a modification of that
code and see what happens. Yes! Break it (but don't submit a patch that
does ;). Sometimes breaking stuff is the best way to understand why it
worked in the first place. Use function graph tracing to see the code
flow.
After you have done that, and you really have a good understanding of
that part of the kernel, you should in the mean time see a way to
enhance it, or better yet, find a real bug and fix it. Then you can
submit a patch and that will be something of use.
Moral of the story: Learn the kernel before submitting a patch, do not
submit a patch to help you learn the kernel.
-- Steve
--
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