Mark Martin wrote:
> Brian Cameron wrote:
>>
>> Although there may be some things in OpenSolaris that have not gone
>> through careful review, the bulk of it has. So, I'd expect problems to
>> arise, for example, if a case wants to import interfaces that have not
>> yet been ARC'ed.
>
> Brian, thanks for your comments.
>
> While I won't disagree that the bulk of packaging (at least) has been
> reviewed by some project teams, I'm not so sure OpenSolaris(tm) the
> distro has been reviewed openly, nor has much of it been defined in or
> for the ARC. Other than PSARC 2008/190
> (http://arc.opensolaris.org/caselog/PSARC/2008/190/)
> <http://arc.opensolaris.org/caselog/PSARC/2008/190/> and LSARC
> 2008/492 (http://arc.opensolaris.org/caselog/LSARC/2008/492/
> <http://arc.opensolaris.org/caselog/LSARC/2008/492/>), I don't see
> much of anything else defined strictly for benefit of committee
> members. And I know teams have been planning to bring more forward
> for over 2 years now.
There is nothing in closed areas (at least not that I'm *aware* of) that
has been reviewed by PSARC with respect to OpenSolaris. Indeed, I doubt
I know anything more (as an internal engineer) about the plans for
OpenSolaris than you do.
The issue at hand, I think, is not whether the OpenSolaris team is
operating within "closed" doors, but whether it is operating in an
ARC-reviewed manner. To date the explanations given for not coming to
ARC heretofore have been that the project team simply doesn't have time
or resources, or is not ready, for ARC review.
I doubt I'm alone on the ARC in that I'd like see the full plans
properly reviewed at ARC, and clarification about future release
strategies provided. In the meantime, we muddle along as best we can.
We *know* that SXCE is ending (this was announced). We don't know what
future release strategies are going to be, but we *suppose* them to be
based around the OpenSolaris distribution.
One problem, fundamental to the whole discussion, is that ARC is on the
one hand very concerned with release boundaries. But on the other hand,
release boundaries are totally governed by the distribution builders,
and distributions are something that historically fall *outside* of ARC
control.
Possibly we (OpenSolaris ARC) should look at finding a way to define
clearer release boundaries for the "foundation" that maybe aren't tied
to specific distributions. This would seem to be cleaner (from a
reviewers standpoint), and yet also uglier (from a consumer's
standpoint, since it makes it harder to understand "what is a release"
and judge compatibility promises or stated intentions correctly.)
- Garrett
> What I'm really trying to make sure is that as a reviewer, I know how
> to apply answers to the following:
>
> -What are the release boundaries with OpenSolaris 20yy.mm? Does that
> count as an official release, or is Solaris.Next something else
> altogether different and we haven't reached a micro or minor release?
> Are release boundaries still continually tied to the commercial
> distribution as has historically been the case? Is a repository more
> like a stream, or is it strictly bounded by release semantics?
> -What is the difference if a project targets /release vs. /contrib?
> Almost every project ARCing today is Sun funded and therefor very
> likely targeting /release. -Suppose I get a few folks together and we
> port package W and want to target /release and bring it through ARC?
> Does choice of repository affect stability levels? Could an
> externally resourced team bring a Committed library through and target
> /release? There's enough doubt raised in my mind since /contrib is
> being lofted about as the repository of last resort. Do different
> stability levels apply? Do release boundaries change? How is an ISV
> supposed to determine this?
> -What's the story with the packaging? Do I need to worry how
> dependencies are maintained? If a Python project comes through
> supporting 2 major versions, do I just assume the same old
> installation/co-existence semantics apply? Does "patch" level binding
> just fall away?
> -Near as I can tell, IPS offers no post packaging scripting ability,
> so what do I assume could happen when things are upgraded? What's the
> story on deferring post-install actions to some SMF service? What
> does that mean for an admin? A desktop user?
>
> This isn't a complete list -- these are just some of the types of
> questions I think may or may not be answered if I go digging around
> and asking on email lists. Do either ARC's care that answering these
> types of questions is not easy? I'm simply asking if it's OK to guess
> here, or assume that project teams have insight or knowledge that
> perhaps I, as external contributor, may not have access to. Again,
> I'm not looking for conspiracy or confrontation, I'm just expressing a
> bit of discomfort I feel knowing that any meager review I might be
> able to offer is based on an incomplete picture of what it is exactly
> that projects are finally integrating into. I have my own misgivings
> regarding some of the architecture and semantics at play, but do I
> take the ARC's apparent silent acceptance of the new reality as proof
> that you folks, whom I consider much wiser and more experienced than
> I, are satisfied with the definitions available today?
>
> Presumably I'm not alone in thinking that the next evolution of
> Solaris, if it truly is OpenSolaris(tm) 20xx or something really darn
> close to it, changes some fundamental things. Software is delivered
> differently. Patches are delivered and applied differently. It's
> released differently. The way the system boots and is upgraded is
> managed differently. The choices for the way projects integrate has
> changed. Much of the technical details of all this can probably be
> found by poking around some of the various community projects. Some
> of it may be based on goals defined by internal teams. When applying
> my humble experience, how much do I assume and how much do I ignore?
> What's the ARC using as Canonical reference for OpenSolaris(tm) these
> days?
