On 14-09-17 07:20 AM, Robert P. J. Day wrote: > On Tue, 16 Sep 2014, Greg KH wrote: > >> On Tue, Sep 16, 2014 at 11:42:18PM -0400, Valdis.Kletnieks@xxxxxx wrote: >>> (And this sort of analysis is exactly *why* people need to apply their brains >>> when looking at checkpatch output....) >> >> No one has ever said that they shouldn't. >> >> Remember, I know _lots_ of kernel developers who started with just >> "checkpatch cleanups on staging drivers" and they moved on to much >> "higher" roles in the kernel developer ecosystem (jobs, maintainers >> of subsystems, keynote talks at conferences, etc.) >> >> Don't "po po" it as something that shouldn't be a valid place to >> start, it is, and is why I do the work to review all of the many >> thousands of staging patches every release cycle. >> >> No one is forcing you to write those patches, or read / review them, >> so don't discourage others to provide them either please. I most >> certainly do not. > > so while i'm waxing philosophical, some other thoughts that occurred > to me that reflect on how i got started, and ways to become a more and > more useful contributor to the kernel for newbies (and i'm willing to > be corrected on any of this). > > first, stop with the blind running of checkpatch unless you're > willing to take the results and examine the *context* in which they > occur. that file needs blank lines? ok, does it reside in a directory > of related files that could *also* use some blank lines? then do them > *all* -- don't waste peoples' time fixing one file at a time. if you > can do the same stylistic cleanup on an entire subsystem, go for it, > and don't clutter up the git log with numerous trivial commits. > > *but* ... don't try to sneak functional changes in there at the same > time. if it's a style cleanup, then it's a *style* cleanup. one thing > at a time. but there are other places you can make a name. > > first, read the Documentation/ directory -- there's lots of content > there, and quite a bit of it is out of date or just plain obsolete. > and if you want people to love you, improve the documentation. but, > see, that's going to take some work. and that's because it requires > you to read the documentation, then go off and examine the > corresponding code to see if it still matches. and why is this good? > > because while updating the Documentation/ content is safe and can't > break anything, the side effect is that you *learn* about that > particular subsystem, you get some nifty patches into the kernel, and > you make lots and lots of friends. > > another place to get cheap patches is to repair any kernel-doc > warnings, and there are *always* plenty of those. again, fixing > kernel-doc content shouldn't break anything, it should be easy > patching, and it normally requires you to at least examine the code to > make sure you're fixing it properly. so, you get patches into the > kernel, and you learn a bit more about some code. win-win. > > last point here regarding something gregkh wrote -- yes, it's fine > to *start* with simple stylistic cleanup, especially if checkpatch > does all the work for you. but remember, that's low-hanging fruit, and > you shouldn't be greedy and try and do all of it. if stylistic cleanup > is a way for beginners to get their first patches into the kernel, > then don't be a pig and try to do it all -- leave some for others to > cut their teeth on. and what is the point of all this? > > quite simply, this is also why nick krause will never be a useful > member of the kernel community. i suggested a while back that nick > could start with improving the documentation, for all the reasons i > mentioned above. his response was that he didn't know enough to do > that, which is an astonishing thing to admit. if you don't know enough > to improve the basic documentation, you have no right to be mucking > around in the code. > > and, as we've all seen, nick's other flaw is that, quite simply, > he's selfish and greedy. his entire obsession is with the output of > checkpatch, which means he wants to grab all the trivial cleanup (the > low-hanging fruit, as it were) for himself, and not leave any for > others. rather than take the time to understand the code, nick wants > checkpatch to do all the work for him. in the end, nick doesn't want > to do any work or understand how the kernel actually works -- he just > wants patches, and he wants them as quickly and cheaply as possible. > > anyway, it's time for coffee. > > rday > Rday and others, That's not what I wanted I was trying to improve my rep after getting banned from vger.org and now it seems I can't even get a patch right. In addition I was trying to do check patch because it was easier for me due to not understanding some parts of the code. Nick _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
