Tips for OpenSolaris CFF participants

Here are some tips for OpenSolaris CFF participants: 

  • Read how to contribute to OpenSolaris at: http://blogs.sun.com/jkini/entry/contributing_to_opensolaris
  • Install OpenSolaris and download the source \*before\* you submit a request for a mentor.  Look at the source and get familiar with building one command (not the whole source).
  • Its not necessary to build (nightly) OpenSolaris to start with.  First identify the bug/RFE.  Then decide whether a nightly is required or building one part is sufficient for the code changes being made.  Your mentor can help you with deciding this part.
  • Confirm that the bug is not being worked upon by another contributor at http://opensolaris.org/os/bug_reports/request_sponsor/
  • There is a very good chance for an RFE to require a PSARC case.  PSARC case has a longer process which will delay the integration of your changes into OpenSolaris.  On the contrary, bugs have a negligible chance for a PSARC case.  I'm not discouraging you to pick up RFEs.  Just setting expectations.
  • If the code contribution is made before Feb 14 2008, then it'll be considered for the CFF contest.  It need not be integrated by that time.
  • Note that http://bugs.opensolaris.org is synced with the Sun Internal bug database every day.  There  have been issues with the syncing process which has caused contributors to pick up the wrong bugs.  Confirm with your mentor that the bug/RFE can be worked upon before you start.
  • Send a mail to request-sponsor alias as soon as you pick up a bug saying you are working on so-and-so bug/RFE and will come back with your contribution within so-and-so date.  This will be updated on the '.../request_sponsor' page.  This will prevent another contributor from picking up the same bug/RFE.
  • Testing the code changes is \*mandatory\*, even for trivial changes.  When you ask for sponsorship, your sponsor will ask you this.  If you have not tested, then you'll be asked to do it.  This will delay your fix being integrated.
  • You can look at the source on opensolaris.org and come up with a fix for simple and trivial fixes.  But, again, you \*must\* compile and test it.
  • Mention a long term email id while sending your SCA.  Currently there is no procedure to change your email id once a SCA is assigned.  It could be difficult to change it later.  If you know your college/institution email id is temporary, get a public domain email id and use that.
  • Mention your SCA number in all mails sent to request-sponsor alias.
  • Mention the dates in country neutral format: dd-mmm-yyyy.  US follows mm/dd/yyyy format while India follows dd/mm/yyyy format.  This can cause confusion.
  • All the diffs submitted to http://cr.opensolaris.org or through an attachment must be context diffs or unified diffs. i.e. it should be diff -c or diff -u output.  A plain diff will not do.  You can also attach/upload webrev output which will be more elaborate and suitable for reviews.

All the best!
 

Comments:

Post a Comment:
Comments are closed for this entry.
About

jkini

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today