Shares from application experience

Shares from application experience

[Alison Schofield]

Hi applicants,

I wrote this after my Outreachy application experience.  Maybe you'll
find something useful inside.

Here are my top shares from the application period:

o First Patch Tutorial

  Follow the first patch tutorial and review it periodically.
  You can submit your first patch without understanding the details
  of everything the first time, but as you move along, things in there
  may become more important, and will make more sense, so review it
  once in a while.  Each time you'll get another a-hah!

o Doing code cleanup

  I starting out hating it, and ended up hating it less ;)
  Although it seems pretty superficial it's scary because you are
  touching code that you don't completely understand nor are capable
  of testing.  The positive side to this is that it forces you to
  concentrate on your pure C development skills and be a very careful
  reviewer.  You do learn a lot, you start to see patterns...it's good!

o Checkpatch'ing your patches

  The checkpatch check that the first patch tutorial instructs you to
  put in your git tree, will print a message if the commit you are
  doing has a checkpatch error (CHECK,WARNING,ERROR).  Follow the
  directions, and create it and test it.

  If you're thinking, hey, I'm running checkpatch all the time, I don't
  need this, use it anyway.  It'll catch it if you inadvertently add
  white space or blank line at the last minute.  Look for the messages
  it prints.  It prints the message as you are doing the commit, so you
  don't really see it until you exit the commit.  Make sure you look and
  amend the commit if there is a problem.

  You might be saying - hey, I just want it to abort the commit immediately
  if there is a checkpatch error.  I had that same thought and changed
  it to simply stop the commit. Then I came upon the case where it fails
  for something like camelcase that I didn't insert and I was not intending
  to correct in this patch.  So, you see, there are times you'll want to
  commit anyway.  Note, that'll usually be for checkpatch 'CHECK's,
  not WARNING's or ERROR's.

  And, if you get out of the application period and think you've mastered
  submitting clean patches, I hit upon another gotcha.  That checkpatch
  check you inserted was in the staging git tree you created for Outreachy.
  As you go forward and create other git trees, you will have to replicate
  that checkpatch check in those trees. 

o The Outreachy Google Group Mailing List

  You can follow along on the list in google groups, and/or you can have
  the mail delivered to your inbox.  At first I followed along on google
  groups, but I found when I wanted to comment on a thread that I didn't 
  start, it was hard to do so in google groups.  Remember we want to send
  plain text email.  So, allow the mail to be sent to your (mutt) mailbox,
  and you can delete it easily and also comment easily. 

  Always group reply.

  The mailing list is a great resource to see what comments mentors are
  saying about other patches.  Spend some time there and scroll back 
  through previous Outreachy rounds too.

  Having said that, the list can appear overwheliming.  Here's how you
  might use that: 

  - if you see a patch of interest, you may find it needs to be fixed
    somewhere else in the staging tree

  - if you see a patch you were about to do just got submitted, you don't
    necessarily have to abandon it.  For example, you just created a
    cocci script to find something and all the instances of that have just
    been submitted.  The point is you were trying to demonstrate your
    cocci script and your ability to patch it.  So, go ahead and submit it.
    Let the mentors see it.  Sure, it probably won't make it into the 
    staging tree, but you will still get the patch reviewed.

  - Set &/or evolve your own goals
    Its been my observation that there are accepted applicants who
    submit a bazillion patches and ones who submit a few.  You'll
    want to get your minimum patches completed, so you'll develop a
    strategy for that. Beyond the minimum you'll have your own
    goals and strategy.  For example, I spent hours and hours (and hours)
    on the IIO tasks.

o Are you sure you COMPILED that?

  The mentors are extremely patient with everything, but if I *had* to
  pick a worst offense, I would choose failure to compile.  

  Checkpatch errors, munged email, coding/logic errors, bad log entries,
  formatting issues, are all caught on review and that's why the whole
  firstpatch process exists.  But, a compile error, which is not always
  caught on review, breaks someones build, and so that's costly.  
  
  Of course, no one intentionally doesn't compile!  So, before you
  submit be sure you are actually building the module.  The firstpatch
  tutorial explains how to config your module to build.  (Before I 
  decided on a cleanup to do, I made sure I could build that module.
  I can't recall which, but I know I abandoned at least one cleanup
  idea because I couldn't get the module to build.) Go old school:
  remove the .o, see it compile anew.  Be sure.

  For this, a 'sandbox' branch is helpful.  Mail the patch to yourself,
  apply the patch to your sandbox, compile the driver.  Good sanity check!

Catch me though email on on IRC as alisons.

Re: Shares from application experience

[Rehas Sachdeva]

[-- Attachment #1.1: Type: text/plain, Size: 53 bytes --]

Hi Alison

This is really valuable. Thanks :)

Rehas

[-- Attachment #1.2: Type: text/html, Size: 183 bytes --]

Re: Shares from application experience

[Namrata A Shettar]

[-- Attachment #1.1: Type: text/plain, Size: 73 bytes --]

Yes, Thanks! for sharing it with us. Really helpful :)

Regards,
Namrata

[-- Attachment #1.2: Type: text/html, Size: 106 bytes --]