Jyri Virkki

Contributing to SFW

As I've mentioned, my group has been working on the web stack project for the last few months. We have integrated PHP into OpenSolaris and the work for Squid has been completed for a few weeks (unfortunately it is still stuck in process limbo, but should be in OpenSolaris soon). One of the interesting aspects of contributing these components into OpenSolaris has been to observe first hand the processes that it takes to get something into sfw - the OpenSolaris consolidation containing open source packages delivered with OpenSolaris.

Open source components in sfw are delivered without changes from the upstream community which delivers each component, since we have no interest in forking and all the maintenance headaches that come with it. We do include some additional bits and pieces (such as smf support) which are required to properly operate in the OpenSolaris world, but for the most part delivery consists of hooking up the usual (./configure;make;make install) trio to the sfw build infrastructure and that's it (the hooking up part does take some work since the sfw build system differs from the assumptions baked into most 'make install' targets, but it's not that much work).

However, there's a lot more that goes into actually delivering the bits into sfw. Here's a generalized timeline based on our experiences so far (PHP, Squid):

OSRs refer to the legal approval processes so the component can go into OpenSolaris. There's a number of other smaller overhead process tasks (smaller red blocks) which can occur in parallel with the engineering work, but even those take time away from the engineering effort. After everything else has finished, there are the WebRTI (request to integrate) and c-team processes to run through. When all of those finally complete, the code goes in! (Squid is currently in that zone between the two vertical dotted lines.)

Hopefully this diagram gives some insight into what it takes to get a component into sfw. It might also help explain how come there is such a long lag between the time all engineering discussions are completed on the web stack list and the time the bits actually show up on the sfw sources (no, it's not that we fell asleep!)

One thing I worry about is whether it is possible to attract contributors to web stack given this process structure? If you're interested in helping out, what's your threshhold of pain on process overhead? How can we make it easier and more efficient? Let me know what you think...

Posted at 11:57PM Oct 23, 2007 by jyri in WebStack  |  Comments[2]