From: me@tobin.cc (Tobin C. Harding)
Subject: [OSSNA] Intro to kernel hacking tutorial
Date: Mon, 22 Jul 2019 19:29:23 +1000 [thread overview]
Message-ID: <20190722092923.GB22763@ares> (raw)
In-Reply-To: <20190719093658.GF3111@kadam>
On Fri, Jul 19, 2019@12:36:58PM +0300, Dan Carpenter wrote:
> On Fri, Jul 05, 2019@12:50:55PM +1000, Tobin C. Harding wrote:
> > Outcome will (hopefully) be a small patch set into drivers/staging/.
> > (Don't worry Greg only one group got to this stage last time, you
> > won't get flooded with patches :)
>
> We're good at reviewing floods of patches. Send away.
>
> In the end what we want is people who will take over a driver and
> understand it completely and become the maintainer. We've had a few
> people that did appointed themselves to become the maintainer of a
> random driver and move it out of staging. But even if people don't make
> it all the way to become a maintainer, it's nice when they start down
> that path by focusing on one driver and trying to understand it as much
> as possible.
>
> Most of the time when you look at a new staging driver, then you do want
> to clean up the white space just because it's hard to look at
> non-standard code. So that's the first step. But then maybe start at
> the probe and release functions and clean it up. Keep your eyes open
> to any other mistakes or bugs you see. Write them down. Then the
> ioctls. Etc. Look at the TODO too.
>
> The other thing I wish people knew was about the relationship with
> maintainers. When you start out, you're virtually anonymous for the
> first couple patchsets. We get so many and they blend together so we
> don't remember your name. So don't think that we mean anything
> personally if we don't apply your patch. We have forgotten about the
> patch as soon as we reply to it. Don't panic and resend quickly. You
> will be too stressed. Wait until the next day.
>
> In staging we really want to apply patches (unless it's in staging
> because we're going to remove the code). I get annoyed with other
> staging reviewers who NAK patches because "I don't like churn" or
> whatever.
>
> On the other hand, patches just "silencing checkpatch.pl" is not a valid
> justification for sending a patch. Patches should make the code more
> readable.
>
> Anyway, maintainers are not monsters. Very few people have made me
> annoyed to the point where I refuse to review their code. And everyone
> else is in my good books so that's fine.
Cool, points noted. Thanks Dan
Tobin
WARNING: multiple messages have this Message-ID (diff)
From: "Tobin C. Harding" <me@tobin.cc>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
driverdev-devel@linuxdriverproject.org,
Kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: [OSSNA] Intro to kernel hacking tutorial
Date: Mon, 22 Jul 2019 19:29:23 +1000 [thread overview]
Message-ID: <20190722092923.GB22763@ares> (raw)
In-Reply-To: <20190719093658.GF3111@kadam>
On Fri, Jul 19, 2019 at 12:36:58PM +0300, Dan Carpenter wrote:
> On Fri, Jul 05, 2019 at 12:50:55PM +1000, Tobin C. Harding wrote:
> > Outcome will (hopefully) be a small patch set into drivers/staging/.
> > (Don't worry Greg only one group got to this stage last time, you
> > won't get flooded with patches :)
>
> We're good at reviewing floods of patches. Send away.
>
> In the end what we want is people who will take over a driver and
> understand it completely and become the maintainer. We've had a few
> people that did appointed themselves to become the maintainer of a
> random driver and move it out of staging. But even if people don't make
> it all the way to become a maintainer, it's nice when they start down
> that path by focusing on one driver and trying to understand it as much
> as possible.
>
> Most of the time when you look at a new staging driver, then you do want
> to clean up the white space just because it's hard to look at
> non-standard code. So that's the first step. But then maybe start at
> the probe and release functions and clean it up. Keep your eyes open
> to any other mistakes or bugs you see. Write them down. Then the
> ioctls. Etc. Look at the TODO too.
>
> The other thing I wish people knew was about the relationship with
> maintainers. When you start out, you're virtually anonymous for the
> first couple patchsets. We get so many and they blend together so we
> don't remember your name. So don't think that we mean anything
> personally if we don't apply your patch. We have forgotten about the
> patch as soon as we reply to it. Don't panic and resend quickly. You
> will be too stressed. Wait until the next day.
>
> In staging we really want to apply patches (unless it's in staging
> because we're going to remove the code). I get annoyed with other
> staging reviewers who NAK patches because "I don't like churn" or
> whatever.
>
> On the other hand, patches just "silencing checkpatch.pl" is not a valid
> justification for sending a patch. Patches should make the code more
> readable.
>
> Anyway, maintainers are not monsters. Very few people have made me
> annoyed to the point where I refuse to review their code. And everyone
> else is in my good books so that's fine.
Cool, points noted. Thanks Dan
Tobin
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2019-07-22 9:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-05 2:50 [OSSNA] Intro to kernel hacking tutorial Tobin C. Harding
2019-07-05 3:32 ` Amit Kumar
2019-07-05 3:32 ` Amit Kumar
2019-07-05 5:10 ` Amit Kumar
2019-07-05 5:10 ` Amit Kumar
2019-07-08 23:46 ` Tobin C. Harding
2019-07-05 7:48 ` loïc tourlonias
2019-07-05 7:48 ` loïc tourlonias
2019-07-19 9:36 ` Dan Carpenter
2019-07-19 9:36 ` Dan Carpenter
2019-07-22 9:29 ` Tobin C. Harding [this message]
2019-07-22 9:29 ` Tobin C. Harding
2019-09-01 0:00 ` Amit Kumar
2019-09-01 0:00 ` Amit Kumar
2019-09-02 1:51 ` Tobin C. Harding
2019-09-02 1:51 ` Tobin C. Harding
2019-09-02 6:29 ` Amit Kumar
2019-09-02 12:42 ` Anatoly Pugachev
2019-09-02 12:42 ` Anatoly Pugachev
2019-09-02 14:08 ` Valdis Klētnieks
2019-09-02 14:08 ` Valdis Klētnieks
2019-09-03 1:49 ` Tobin C. Harding
2019-09-03 1:49 ` Tobin C. Harding
2019-09-04 9:55 ` Anatoly Pugachev
2019-09-04 9:55 ` Anatoly Pugachev
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=20190722092923.GB22763@ares \
--to=me@tobin.cc \
/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.