Well, I managed to get my first patch into OpenSolaris. It wasn’t anything major, just a couple simple script fixes but, it did get me to go through the entire process of contributing. A bit of a daunting task as there are a lot of things to keep in mind.
I also opened my big mouth and suggested an article for new developers.
I’ve decided to put some form of money where my mouth is. Possibly Monopoly money.
Anyway, here goes, some information to keep in mind when contributing to OpenSolaris.
OpenSolaris can be a bit of a frightening community. There is a lot of stuff going on over there. Some parts have a lot of activity, some have none. I guess like any community. The problem with this is it can be really daunting to get involved. Where do you start? What do you need to contribute? Hopefully this article will help.
Your first step on this road is to start getting involved in the communities. This really depends on what you want to help with but in general, signing up for OpenSolaris Discuss is probably a good place to start. After that it depends on what you want to do. If you’re looking to submit code patches it’s probably a good idea to sign up to the OpenSolaris Request Sponsor list which I’ll explain in a little bit. There are also lists relating to documentation, new users, system administrators, DTrace, ZFS and many others. Take a look through the OpenSolaris Forums page and see if anything strikes your fancy.
Ok, the rest of this article is going to be coming at this from the coding perspective as that’s where I’m coming from. Things are probably similar if you’re helping out in the other parts of the community.
Before you’ll be able to commit any code back to OpenSolaris you’ll need a contributor agreement. This is an agreement between you and Sun giving joint copyright on the code you submit. Without this agreement your code won’t be allowed back into OpenSolaris. You can learn more, and actually get the agreement on the agreement page. There is also a contributor agreement FAQ available.
When the agreements have been processed by Sun you will receive a contributor agreement number. Hold onto this number as you’ll need to reference it when submitting code.
While our agreement is off being reviewed by Sun we can go ahead and get ourselves setup to do some development. The first thing you’ll need is a base system to install OpenSolaris onto. You can get more information on getting setup here. The downloads page also gives some links to various distributions and build instructions.
Once you’ve got a base system installed you can either grab the current source code as a tarball or from the Mercurial repository. The tarballs are available at: http://dlc.sun.com/osol/on/downloads/current/ and Mercurial information is available on the project page.
The process to build and install the software is laid out in the README and in the Developers Reference Document.
When you get everything installed correctly, and if you’re like me this means doing it at least twice as the first install turned the computer into a brick, you can start fixing bugs and adding features.
There are a few different places you can look for stuff to work on if you don’t have something in mind already. The OSS Bite Sized list is a good place to start. These are bugs that are considered small and good starting points. Before embarking on any of these you might want to check the Request Sponsor list to see if anyone is working on the bug yet.
You can also search the bug database for other bugs to work on. A couple of the possible search keywords include:
- oss-bite-sized
- speeling
- oss-request
When you’re change is complete you’ll need to make a diff of the change to send in for review. There are a couple of different ways to do this depending on what system you used to receive the code.
If you’re using Mercurial you can do something like (note my Mercurial usage sucks and there is probably a better way to do this):
hg commit
hg export tip
This will output a diff of the last change commited. You can also do hg diff and give it a revision number to get all the changes from that revision.
If you’re working with a tarball then you’ll probably want to resort to trusty diff. Before you start editing a file make a backup copy of the file and then something like diff -u file.old file should do what you need.
With your diff in hand you can now send it into the request sponsor mailing list. In order for your code to be put back into the main repository you require a sponsor within Sun. The request sponsor mailing list is where you can go to ask someone to sponsor your work. In order to make it simplest for the developers you can set your subject line to be the bugid and bug synopsis (eg: 6489619 *nightly* options list should be sorted) or, if the patch fixes multiple bugs, just list the bug ids in the subject.
The body of the email should contain, again, the bug id, the bug synopsis, your contributor agreement number and have the patch attached. Any other information you think is relevant, like why you fixed the bug in a specific fashion can also be helpful.
At this point, hopefully, a Sun engineer will pickup the bug and run with it. They’ll integrate your patch into their repository, do some testing, send out a request to get some reviewers and all the other dirty work. There is probably a good chance they’ll come back and ask for some changes to the patch. Nothing to worry about, this is normal. Make any needed fixups and send them a new diff.
If the patch changes something fundamental in Solaris then you might need to get ARC review. I’m not exactly sure how this works as I’ve never had to deal with it. Just listed here as a quick heads up.
That’s it. Hopefully at this point you’ve got something integrated back into OpenSolaris.
Resources
