Program technical status, 9 September

[Reposted from forum thread.]

I’ve had a few weeks to get oriented and thought I would bring folks up to date on the work we intend to pursue in the short term. My primary concern after an initial survey is creating additional infrastructure to get currently internal-to-Sun projects and conversations out in the open, on the opensolaris.org site, before the development phase of Nevada closes, and we move into a more limited Beta phase, where project work starts to focus exclusively on integration readiness.

That is, even though we are working to define and transition to a community development process and governance model, I don’t want the absence of the documents describing such things to be an excuse for not moving conversations outside. Accordingly, we are working on a number of items that eliminate that excuse. I’ll start with the general items, and then some specific to the ON consolidation.

  1. Elementary project hosting support.

Typically, in terms of communication, projects inside Sun are very similar to projects we see in open source efforts: they have web pages, mailing lists, and download areas. (Some may also have IRC channels, Wikis, and blogs.) Much useful conversation and experimentation can take place using only these media, and so I want to get basic project hosting functionality up on opensolaris.org.

Projects that prefer to host elsewhere can use this facility as a pointer to their primary site, so that they appear in lists of OpenSolaris-related work.

  1. Source code management, first phase.

The Code Manager (“TeamWare”) distributed source code manager (SCM) has been in use at Sun for over twelve years; its predecessors were also distributed SCM solutions. It is difficult to envision how we might move the current practices of the consolidations using TeamWare to an SCM that doesn’t match up well with the features and extensions that have been in use for so long. However, TeamWare itself has deficits when we consider its use on the open Internet (and even within Sun’s wide area network).

In order to make progress, and in order to support new and current projects and consolidations that are not tied to TeamWare, I believe that we must offer a centralized SCM facility while the current set of open source distributed SCM solutions are evaluated against criteria based on TeamWare’s use within Sun and on suitability for use on an Internet-hosted site. Luckily, recent developments in the SCM space suggest that one or more SCMs may meet many of these criteria already. A draft set of criteria will be published shortly, after which candidate SCMs will be evaluated against them.

The proposed centralized SCM solution is Subversion, based on features, ease of integration, and community vigor. Information on Subversion may be found at

http://subversion.tigris.org/

Tools to make the source drops of TeamWare-based consolidations available via a read-only repository will also be found/refined/developed. We will publish a representation of ON via a read-only repository during this phase.

  1. Partitioned ON source tree.

A number of ON-based projects are ready to share their development versions, in code form, on the site. However, the current source publication process for ON is too arduous to expect individual projects to use team member time to handle their own publication. We are thus partitioning the source tree into open (“usr/src”) and encumbered (“usr/closed”) subtrees, so that projects can easily publish and independently buildable open tree containing their changes. This work is already underway.

  1. ON GCC compiler readiness.

Steady progress is being made to make ON builds GCC warnings free. As we are now closing in on a warnings-free build, we will be examining the current build tools to make GCC clean (or, if you prefer, alternate compilation clean) an ongoing requirement for integration, without being an undue burden on contributors. There are numerous possibilities that are opened up by a GCC build, but the primary justification for the present work is that it finds bugs prior to integration.

There are, of course, many other activities going on: Karyn’s list of consolidation priorities hints at what additional code is nearing openness, creation of additional website content, the already mentioned development process and governance and charter work, and the publication of ON source drops. (Plus work in community building and support, marketing efforts, …) I thought I should call out that we have added additional sponsors for ON and that John Beck has been working to close some gaps in sponsor technical coverage, so that code fixes submitted during this interim phase don’t get chilled waiting for a sponsor.

Feedback welcome. I’ll read it all, but I can’t promise replies to all.

[ T: OpenSolaris ]