Reexamining OpenSolaris technical concerns
I’ve recently rejoined the team working directly on the OpenSolaris effort. The past few weeks I’ve been getting caught up on where Open is with respect to a number of areas, both technical and process. During my survey, I’ve been pleased to see how good the current technical team (“I-team”, or implementation team, in local software development framework-speak) is—they’ve got a handle on the complexities of delivering the nearly 36 000 files in the ON consolidation in a partitioned, cleansed form, and are spending a good chunk of time so that the other major source trees that make up Solaris (“consolidations”) don’t have to reinvent these procedures themselves.
There are a number of technical topics—involving how we develop software—that I want to visit over the next few weeks in this blog, because it seems like a reasonable way to describe some of the key aspects to what we’re doing now and lay out the set of issues that need to balanced in any effort to make a principles-driven community development process. For instance, a short list of topics would include at least
- multiple compiler support implications,
- “shrink to fit” architectural processes,
- source code management requirements and options,
- programmatic facilities at opensolaris.org (“web services versus web pages”), and
- workflow tools and support, on and off the site. And probably some other things that are worrying me (like how to keep up with a few hundred additional email messages per day, above the few hundred I was already receiving).
That said, I am happy to hear your concerns, hopes, fears, and speculations about OpenSolaris, and email is, of course, fine.