Contributing to OpenSolaris

05 Mar 2007

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’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.

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.