Brian Cameron <[EMAIL PROTECTED]> wrote:
> Within Sun, certain processes are defined by the ARC (Architectural Review
> Committeee) to help ensure interface stability. Over the past year, I have
> been working with the Sun ARC chairs to determine how free software,
> OpenSolaris, and interface stability process will all get along.
As long as this kind of mail is the only news we see from the ARC, there
is no difference whether it exists or not. Unless the ARC is really open,
it is a Sun internal thing and does not apply to OpenSolaris.
...
> Typically, the need for interface stability is only needed for projects
> that contain interfaces that users/ISV's might depend upon. This type
> of software is distributed in packages that start with the "SUNW" prefix.
> The second kind of software is the software that starts with the "SFW"
> prefix (but is sometimes referred to as "Companion CD" or "/opt/sfw".
> These are applications that are provided to Solaris users but do not
> contain any interfaces considered by Sun to be Stable. Solaris users
> are discourged from using interfaces that do not meet Solaris stability
> requirements, and I believe this rule will also apply to OpenSolaris.
Please note that as long as there is no pkgadd(1M) on OpenSolaris, it does
not make sense to mention packages at all.
...
> Nothing is really "blocking" moving ksh93 code into Solaris. However, it
> is necessary to go through an interface review process that highlights how
> well ksh supports the current interfaces. If no interfaces break (including
> environment variable interaction, ABI, man page is accurate with new
> features, etc.), then replacing an application like ksh is fairly easy.
> If there are differences, then these are discussed in the review process
> and certain resolutions might be necessary (fixing issues with ksh as bugs)
> or some broken interfaces may be considered acceptable.
>
> If the ksh93 program has good interface documentation already, then going
> through a review process should be easy enough. If not, then those people
> interested in bringing it into OpenSolaris may have some footwork to do
> to meet documentation requirements.
Your remarks are nice but they don't apply to OpenSolaris. There is no ksh88 in
OpenSolaris and the ksh88 source is not available, so we need to use
ksh95 in OpenSolaris.
Everyting that is needed for Solaris to work but is missing in OpenSolaris
needs to be replaced by OpenSolaris distributions. This is nothing that
is done by free will of the creators of the distributions but because
there is no other way to deal with the problem. If Sun decides to use closed
source software for their Solaris distribution, Sun decides to be incompatible
with other OpenSolaris based distributions.
If you like to discuss compatibility, you need to discuss whether it is
worse to have incompatibilities between current Sun Solaris distributions
and old one or whether is is worse when Sun Solaris differs from other
OpenSolaris based distributions that are derived from the same OpenSolaris
release.
> Interface stability is important. Many projects within the Free Software
> community already recognize this, including the GNOME project. As the
> above website highlights, the GNOME community already does a pretty good
> job of ensuring interface stability for many of its core libraries.
Compatibility is more important than interface stability. If Sun Solaris
decides to be incompatible with SchilliX, this is worse then if Solaris 11
is incompatible with Solaris 10. If Sun likes to avoid the latter, Sun
needs to provide solutions.
> Sun wants to support customers who might not be willing or able to
> rebuild their applications each time they upgrade to a new version of
> Solaris. Therefore, Sun needs to be careful about informing its users
> what interfaces to use. Really, it would benefit all Free Software OS
> users if the interfaces were well documented in these regards.
Does Sun like to create confusion about the official interfaces in Solaris 11?
...
> I think there are a number of paths that you can take to get
> software in OpenSolaris. One method may work better for you:
>
> 1) Work to get the application into a SFW package. These are
> unsupported and the new ksh would not be the default, but it
> would be a good first-step into Solaris. Someone else may
> bite the bullet and be willing to go through the review
> process to migrate it as default. Having it "soak" in SFW
> for a while will ease its transition.
OpenSolaris does not have packages.
If you like to write text that applies to the OpenSolaris process,
give us pkgadd or don't write about packages.
> 3) Be a vocal person in the Free Software community letting us
> know this is a new interface that you want. If enough people
> say that they want this, then Sun hopefully will find the
> resources internally to do the needed review.
I am, but it seems to be hard to inform all Sun employees about
constraints that cannot be changed by non-Sun people and that
are important for the OpenSolaris process.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
