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

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

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

   - Stephen

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED]  http://blogs.sun.com/sch/


----- End forwarded message -----

-- 
Stephen Hahn, PhD  Solaris Kernel Development, Sun Microsystems
[EMAIL PROTECTED]  http://blogs.sun.com/sch/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to