How to Contribute to SFW
By jyri on Nov 07, 2007
A short while ago I posted an overview on contributing to SFW. Internally I maintain a document which goes into detail about all the steps it takes to get a new component into SFW. For a long while I've been meaning to post that document externally so it is available for all of opensolaris. Tonight I took three starts at doing that but there's so much in it that is specific to Sun's internal network that it just doesn't translate very well.
I'm very much looking forward to having the SFW migrate to a mercurial repository on opensolaris.org. That should bring the internal and external build steps much closer (though much will still remain). I think I'll take another stab at a unified process document once that happens.
Still, I'd like to at least summarize the steps for the benefit of anyone interested in contributing to Web Stack (or elsewhere into SFW).
Kick off the processes
- Have your Sun sponsor file OSRs (open source reviews) to get approval to include this components. This takes about a month (or more) so you want to get the process started before anything else!
- Hold discussions on webstack-discuss on all the design details (supported options, file layout, packaging and so forth) until there is consensus on what to do
- Decide on the package names and reserve them (through an internal tool) to avoid naming conflicts
- Write a specification documenting these details. This will be the basis of the ARC review, so follow examples of past ARC cases to make sure the correct info is there
- ARC review. There's a lot more about this here: http://www.opensolaris.org/os/community/arc/
- See http://www.opensolaris.org/os/project/sfwnv/Documents/install_quickstart/ for the basics of getting the source tree and build environment.
- After building the fresh tree once, add your component under usr/src/lib or usr/src/cmd
- Add the source tarball as-is into your newly created directory
- Create a Makefile.sfw which will
- extract the tarball at compile time
- optionally apply any patches if necessary (we try to avoid any)
- run the usual ./configure step with appropriate options
- call make, then make install
- You'll need to spend some time to get the above working correctly because the build needs to install into a 'proto' directory at the top level of the source tree whereas most components assume they can install directly into their ultimate destination
- Optionally (but nearly always) create an install-sfw and install-sfw-64 scripts which fine tune the installation (the component's own 'make install' probably won't do exactly all the right things)
- Create package directories under usr/src/pkgdefs and populate them properly
- Hook up the component and package builds in their parent directory Makefiles
- On all of the steps above, use the existing components as examples (but beware cut'n'pasting blindly)
- Run 'nightly' (full) build, expect to get many errors particularly on packaging; fix those up until everything is clean
Reviews and RTIs (request to integrate)
- File a packageRTI documenting some details (like sizes etc) about the new package(s) being introduced. This takes usually under a week.
- Run 'wx pbchk' and go through the output. It will flag a number of errors/inconsistencies in the workspace. Some of the errors aren't, but go through the list carefully.
- Generate a 'webrti' and publish it on http://cr.opensolaris.org/
- Discuss the changes and get code reviews on webstack-discuss (and/or sfwnv-discuss if relevant)
- Fill out the c-team checklist (I don't think there is a copy on opensolaris.org) and go through review cycles on that. This should take 1-2 weeks.
- Submit a 'WebRTI' (internal tool) with most of the same info as in the previous checklist. This will take about a week.
- Once everything is approved, your Sun sponsor can do the final steps for a putback...