Redirecting to arc-discuss as I believe that's the proper mailing list
for these general threads (while bcc'ing psarc-ext.)
> For the folks looking to integrate software many for consumption in
> Indiana -- lets figure out how to get this into an IPS repo somewhere (I
> believe IPS repos work now for Indiana at least), so we can make the
> Indiana folks (users and developers alike) happy.
>
> Those cases probably don't need to come before ARC right now --
> particularly since IPS itself isn't covered by ARC. Instead, just keep
> a record of what FOSS software is in the IPS, and it can be part of a
> "master list of initial software" that is included with the Indiana/IPS
> ARC case, if/when it comes before ARC. (Also, it appears that the
> Indiana CTeam, if there is one, isn't requiring ARC approval for
> commitment.)
>
> The FOSS packages which need to ship as part of Nevada -- they should
> still come before ARC. Hopefully those packages have wider appeal, or
> somehow fill some kind of architectural gap/vision beyond "make all FOSS
> software available".
>
> My guess is that a lot of the packages that are interesting to a small
> minority of people probably don't really need to be in *Nevada*, and
> hence can probably skip the overheads associated with integration there.
Although I personally believe Indiana is the basis of Solaris Next, it
currently lacks a number of features which makes it unsuitable for
certain users. Until those gaps are addressed (and yes, going through
architecture review is definitely one of those gaps to address), Nevada
as a collection of consolidations (and it's manifestation, Solaris
Express Community Edition) will continue to exist. As such, I would
argue there is benefit to including many of these FOSS components given
that the *intent* is work with the upstream community and properly
maintain them over time.
What precisely are the architectural issues that these FOSS cases are
causing to the current minor release under development? I know that
among others are
1) Some (most?) of the FOSS components may not adhere to one or
more of Big Rules or other policies that have traditionally
covered components that are considered more "core".
2) Is there a duplication in functionality and does providing
alternate implementations mean it becomes difficult or
impossible to build a system architecture? An example of a
potential case that I see as causing such a problem might be
"Integrate initng into OpenSolaris" while I don't necessarily
see that with "Integrate MyFTP into OpenSolaris" (and it seems
so far most of the cases are of the latter variety.)
What are some of the other general architectural issues of concern?
If there was no Indiana and instead the intent was that Solaris Next
was going to continue to ship with a variation of its existing product
structure (a WOS on perhaps Super-Blue-ray(TM) using LZMA2 compression)
would these FOSS components be of no benefit and unsuitable for the
release?
Is there no benefit to integrate these components with a set of
commitment levels so that others (at Sun, ISVs, developers, OpenSolaris
users) can use them under those stated levels unless said components
are unique in functionality and completely integrated with all other
aspects of the system?
dsc
