On Tue, Jan 22, 2008 at 11:46:38AM -0500, James Carlson wrote:

> > One community group in charge of all distributions seems too broad.
> > For making the decisions about the distro itself, like each distro's
> > release plans, it would seem a separate community group is necessary
> > - for example, why would Ian have a vote on Schillix release plans or
> > Joerg a vote on Indiana release plans?
> 
> Actually, I think we'll need to get to that point, at least in some
> cases.
> 
> It seems impractical to me to say that the release binding and
> schedule in use for something as big as ON is just "whatever."  It
> needs to be something that the consumers of ON (that is, the
> distributors) agree on.  If they can't all agree on one setting, then
> they'll need to fork ON into separate streams to contain various kinds
> of content, because there will inevitably be world-changing features
> (such as SMF in the past) that can integrate into a release of one
> binding, but not another.

The way I've started thinking about this problem (and Mr. Walker's
proposal) is to define some nomenclature.  Whether you like my names
is not really important; the fact is that these things exist, or could
exist.  Nothing here should be taken to be a grant of trademark rights
or a statement of SMI's position, etc.

Consix - The consolidations that exist currently, whether or not
         represented by a functioning Community Group.  This is the
         freely-distributable portion of the content that makes up
         Solaris Express.  Consix is not itself a product but is
         available for others to consume.

Consix Community - The remains of the organisation originally formed
         as the OpenSolaris Community.  This organisation is
         interested in the maintenance and development of Consix.

OpenSolaris - A product of Sun Microsystems, Inc. (SMI).  This product
         may or may not be based in whole or in part on Consix (see
         below).

OpenSolaris Community - A community of users and distribution
         developers interested in OpenSolaris, the OpenSolaris
         Distribution Constructor, and the OpenSolaris workalikes
         created thereby.

OpenSolaris Distribution Constructor - A product of SMI that enables
         third parties to create OpenSolaris workalikes in ways that
         allow them certain uses of SMI's trademarks.

Note that the OpenSolaris Community and the Consix Community could in
theory be parts of the same organisation; this isn't meant to suggest
a particular political structure but rather a description of roles.

The first question we need to answer is whether OpenSolaris consumes
Consix.  There are (at least) two possible models here.  In one model
- let us call it Alpha - Consix continues to exist as a separate
collection of technology independently developed by the Consix
Community, and the OpenSolaris Community takes snapshots or releases
of Consix from time to time to develop into its distribution products.
In the second model - Beta - Consix, if it exists at all, is entirely
separate from OpenSolaris.  Instead, the OpenSolaris Community forks
from Consix at inception and never looks back.

Model Alpha does indeed require some mechanism by which consumers of
Consix - prominent but not exclusive among them the OpenSolaris
Community - must agree on release bindings and schedules.  This
suggests a need for some arbitration or steering committee within the
Consix Community.  The $64,000 question, of course, is how it would be
structured.

Model Beta does not really have this same problem, because the
OpenSolaris Community owns its entire source base.  Workalike
distributions are by design and intent subordinate to OpenSolaris
itself, so the people responsible for managing OpenSolaris's
repositories have all necessary authority to make decisions about
releases and bindings.  In this model, the Consix Community still
needs some way to determine when to change utsname and what it means,
but I think the Consix Community would have less difficulty with
contributor-driven decision-making if the OpenSolaris folks can go
their own way.

It's not clear to me whether this proposal is intended to be a part of
the Consix Community or the OpenSolaris Community (that is, which
model is assumed).  Nor is it clear that it fits well into either.

The Consix Community has adopted a set of "Community Groups" that are
in effect SIGs.  They are narrow in scope and rarely encompass
conflicting interests.  Mr. Walker's proposal does not adhere to that
model at all.  There is no doubt that something has to replace the
historic W-teams, but I do not see why a Distribution CG would do this
more effectively than Mr. Coopersmith's previous proposals or some
other mechanism.  And I'm troubled by your suggestion that the right
of suffrage derives primarily from consumption rather than production;
that's not an idea found anywhere in the Consix Constitution.  Still,
as the OpenSolaris CG rather than the Distribution CG, a proposal not
too unlike this one might fit neatly into the Consix Community: one
may note that a single distribution appears to fit very neatly into
the definition of a Community Group as described by the Consix
Constitution and as envisioned by Mr. Fielding.

If this is intended for the OpenSolaris Community, I think it needs to
be considered in light of whatever kind of governance structure that
community will want.  If they intend to inherit as if by fork(2) the
OpenSolaris Constitution, they need to think about how your plan fits
in.  Frankly, it seems to me that what you are proposing is not a new
Consix CG but rather the OpenSolaris Community itself, under which
there might exist political subdivisions for the various OpenSolaris
workalikes but de facto absolute control of shared technical strategy
lies with the trademark holder.

Inherent in my thoughts here is the idea that Consix and OpenSolaris
aren't really compatible ideologically.  Maybe I'm wrong about that.

-- 
Keith M Wesolowski              "Sir, we're surrounded!" 
FishWorks                       "Excellent; we can attack in any direction!" 

Reply via email to