Re-thinking this... OSNet maybe needs to be designated special status in
the OpenSolaris Community/Project structure. It's "neither fish nor fowl".
We don't want to encourage forking at the core (kernel) level,
But we do...
This is exactly what "releases" are - the future development efforts
fork off of the release that is being spun out.
The OSNet umbrella community is the parent for the set of
development and release consolidations that it produces.
For illustration, consider how Sun does this (using Sun historical
terms because the OS.o world is still discussing such things):
There is the ongoing ON development gate. For this
example. lets look at the Solaris9 to Solaris 10
transition.
At certain times, the dev gate is cloned/forked/split
to produce a release-chartered consolidation. This
split usually happens at the end of the development
cycle, at the point where "new features" are forbidden.
(dev complete, feature freeze, code complete...)
For ON81(aka Solaris9), we got to the feature freeze
point a couple of months before the projected GA/RR
masters were to be built. At this point, the development
workspace was cloned (via a teamware workspace child
of the dev gate), the old dev gate became the S9 release
gate, and the new child became the so-called ON10 dev
gate. For the period of time between this split and the
release of S9, all bugfixes made to the S9 gate had to be
manually replicated in the S10 dev gate as well.
As soon as S9 was Released, it was cloned again, creating
(as a parent), the S9 baseline workspace for all patches,
as well as (as a child) the development workspace for
S9update1. As time went on, S9u2, S9u3... all were cloned.
This gives a hierarchy of workspaces - they are all versions
of the OSNet consolidation, they are all related in specific
program-management ways, and each is a fork of the core kernel.
In the OS.o world, this set of relationships is not captured
very well, but it needs to be. Thus my earlier proposal[1] to
revamp the structure to include Communities, Components
and Projects.
-John
____
[1] http://www.opensolaris.org/jive/thread.jspa?messageID=99119𘌯
==============================
I would like to see this evolve into an environment where there are
three types of grouping: COMPONENTS, COMMUNITIES and PROJECTS.
COMPONENTS (such as ON, Documentation, JDS) would be very much like
C-Teams or Steering Committees. They manage source trees and have
a set of PROJECTS under development. COMPONENTS will require a long
term commitment and a small set of core developers to guide them over
their lifecycles. Think of traditional Sun Consolidations, Source
Forge projects, and the various Apache efforts. The tasks related
to managing a COMPONENT are gatekeeping, publishing of "releases",
program management, prioritization of PROJECTS, schedule related
decision making, etc.
Next come COMMUNITIES, which are the social groups that do things
that cross COMPONENT boundaries. They have their own web and hg
archive repositories, but their focus is on leveraging some common
theme across many COMPONENTS. User Groups, Performance, Security,
ARC and Marketing all fit here. COMMUNITIES are expected to be
cheap and easy to create by anyone (think Yahoo/Google/NetNews
groups). They are also easy to disband. Among their "tasks" is
to be a fertile source for new ideas that drive the creation of
PROJECTS in various COMPONENTS.
Finally, PROJECTS are where development work actually gets done.
PROJECTS fall out of the daily evolution and growth of COMPONENTS
as they interact with the various COMMUNITIES. Think of
PROJECTS being equivalent to bugfixes and RFEs... PROJECTS can
be managed (ARC, design and code reviews, schedules and
roadmaps, ...) have sets of contributers (core and otherwise)
affiliated with them, and integrate back into their COMPONENT.
PROJECTS can be nested, providing for things like a PRINTING
PROJECT having bugfixing subprojects as well as new feature
developments like Presto and Tamarack within its scope.
_______________________________________________
opensolaris-discuss mailing list
[email protected]
