Joerg:
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.
I agree, that a reasonable interface stability policy needs to be adopted
for OpenSolaris. I'm fairly sure that such policies are in the works. I've
cc:ed ARC-chair Ed Hunter for comment. He is working on ARC/Free Software
planning.
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.
Fair enough, regardless of how OpenSolaris is distributed, I suspect that
there will continue to be a need to identify which interfaces are Stable
for end-users. The place where interface stability is identified is in
the Attributes section of the manpage. My suspicion is that the manpage
will continue to be where users will look to find out this information
(not the package prefix).
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.
Another option is that OpenSolaris may exclude certain modules, and
distributions who want to use OpenSolaris may include whatever makes the
most sense for them. Once a migration path from ksh88 to ksh93 is in
place, then upgrading OpenSolaris to include ksh93 as a default may make
sense.
The suggestion that both Solaris and OpenSolaris include /usr/bin/ksh93
with Solaris including a /usr/bin/ksh symlink to /usr/bin/ksh88 and
OpenSolaris including a symlink to /usr/bin/ksh93 might also be a
reasonable way to work around issues like this.
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.
Providing both ksh88 and ksh93 might be the right answer for supporting
both compatibility and stability.
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?
No more than Debian likes to create confusion about its licensing.
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.
Sorry, I am not aware of what the process will be, or if it will
include Solaris packaging.
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.
It will probably take a bit of time for the processes to be worked
out. It's probably better than OpenSolaris is working out the
process now with community involvement rather than trying to
simply dictate what the process should be. So, before we can
really start worrying about issues like ksh, we need to figure
out the process. So, helping to get this figured out might be
a good way to move forward. Hopefully Ed will have some comments
about what people can do to get involved.
Brian
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
