Mike Kupfer wrote:
Or are you saying that unless the various components go through an
explicit freeze/stabilize/release process, there is no way for a distro
to put together something that is stable enough to be useful?
Until the contributing consolidation explicitly produces a tagged/blessed
release, one that is intended to be used by consumers as the basis for
distros or whatever, there is no way for any "outsider" to determine
whether or not the raw source bits are in any usable or supportable state.
A distro certainly could choose to build on such an unknown quantity, and
in fact, with the "Release Quality All The Time" mantra that ON is (in)famous
for, the risk or downside of such a choice today for ON is relatively low.
More to the point, such a policy is probably at the root of this current
misunderstanding about the differences between a "release" and "a work in
progress".
This begs the question for ON: What is the practical difference between
A) a raw development build (e.g., hg repository sync'd with the
ON/nv gate on Jan [EMAIL PROTECTED]),
B) a blessed development build (e.g., ON/NVb52, or the version
of ON that ends up in a SX release) and
C) a blessed milestone build (e.g., the release candidate build
that would go into "the Solaris Release following Solaris10"
In my mind, there is nothing wrong with following development builds closely
(A or B) as you develop your distro, but the perception of higher quality that
comes with (B) might be the difference between a "cutting edge test release"
of a distro and a "general use for developers" one; I can't think of any
distro that would release a general use product based on anything but (C).
All of which gets us back to the question of how the various OpenSolaris
Communities plan on creating and managing their individual (C)'s....
Come to think about it, maybe the concept of "Release Quality All The Time"
hints at an answer. If we *never* let the gate become unstable, then we
never need to lock it down to stabilize things. Then every development
build is a (C) and all we need is a better way of doing feature tests.
-John
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
