James Carlson wrote:
John Plocher writes:
I don't understand where this view that OpenSolaris
Communities don't have releases came from.
It's a source base. What's the "release model" for a source base that
has no delivery mechanism?
There is a vast difference between "OpenSolaris" and "The ON
Community that lives under the OpenSolaris umbrella".
The former does not have a release model. The latter must.
OpenSolaris's ON Build 53 is such a release. In the lifecycle
spectrum it is still in the "develop, integrate and test new
features" phase, but at some time its core community will
decide to ease up on the new feature flow, focus on spit and
polish, and bless one of its builds as a formal release for
others to use. This does not imply that that release needs
to be a stand alone product or distro.
In a later messgae you wrote:
> Perhaps I'm just being dense about this, but something
> in there doesn't sound fully baked to me.
Some of that half-baked feeling comes from the fact that the
ON Core Community has not picked up the ball on this whole release
question and the various distros are freewheeling in the vacuum.
Right now, Joerg, Erast and others get to choose between a
set of "pre-release" builds for their distros because there
are no release candidates yet defined for them to use.
That those releases will be "source code", as opposed to the
traditional Sun handoff of a set of binary Masters to
Release Engineering shouldn't be a big issue.
Yes, having all of the distributions agree to a single release
schedule for all of Open Solaris
Parse error. "all of OpenSolaris" is measured in units of
"Communities" while "single release" is in units of "source
code".
Even if we take your comment to mean "agree to a single release
of the ON consolidation", the distros don't really need to agree
on anything. Their choice is simply *which* release that they
wish to use as the basis for their distro, not what goes into it.
If they choose to use the Wednesday Afternoon hg snapshot, so
be it - my opinion is that if there were alternatives, they
wouldn't do it that way :-)
seems flimsy to me. The range of activity permitted by the PACs is
quite constrained, because the type of release and thus primary
release content is set elsewhere.
Yup - in this arena, Sun is explicitly giving up that level of
control for the ON Consolidation. Of course, it is devoutly hoping
that the engineers it has who are working as part of the community
don't all suddenly take leave of their senses and start doing
Stupid Things(TM)....
For example, if the PAC decides it wants to have a radical new Major
release, but the community wants to stick with Minors or smaller
because they are more conservative, we have a conflict we can't
resolve. Are they aware of the implications?
Assuming "They == Solaris PAC", Yes, they are. Or so they say.
I don't believe they fully understand all the implications, but I'm
sure that they see a strong requirement to make it possible.
The current OpenSolaris ON Community source base inherits
the "It is a Minor Release Consolidation" designation made
by Sun's Solaris PAC when the code base was made part of
the OpenSolaris umbrella. The ON Community Core can certainly
change that to "Major Release", or it can charter a brand new
consolidation (aka independent source tree with its own rules)
that runs in parallel with the current one. Or even declare
this one to be done and start another follow on consolidation.
Given the complexities involved with forking and running
releases in parallel, this type of decision shouldn't be
made lightly...
There are many Problems with chartering a Major Release binding
for the ON consolidation - the ones that come to my mind are:
It becomes an attractive nuisance for gratuitous
and disruptive change,
The Consolidation itself is badly in need of refactoring;
major changes to the drivers or admin utilities may be
more acceptable than ones made to libc(), but having them
together in one consolidation makes it hard to make that
type of distinction,
Such a step is not easily reversible if found to have been
a mistake. The current attitude of "we presume that your
changes can be made in compatible ways until you prove
otherwise" means that we always have a stable base to build
upon.
Sun's Solaris Distros may not be able to utilize it due to
release-to-release stability concerns.
Sun's engineers may not be receptive to the idea :-)
Sun's Solaris PAC (management) probably isn't ready to deal
with the issues that will arise out of such a change...
... etc ...
-John
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
