Roy:
On Jul 25, 2005, at 10:43 AM, John Beck wrote:
The first is that all the mechanisms which you rail against are in fact
how things work now.
Yes. I intend to change that.
Everybody involved with Open and Free software is involved with changing
how things work. I think it is great that people are getting involved with
OpenSolaris.
Remember that "how things work now" is evolving. Hopefully, we can figure
out how to change things so that we create a new system that works best,
taking the right directections from both within and outside of Sun. One
area that should receive careful consideration has to do with interface
stability. When this issue comes up, a lot of people seem think its
boring and if ignored, it will hopefully go away. I suspect that the
quickest roadmap to resolving many OpenSolaris issues that are worming
below the surface is to tackle this process isssue.
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.
One of the areas that Sun believes it adds value to the OS market is
stability and support. Therefore, Sun makes more effort than many BSD or
Linux vendors to map out the stability/supportability of interfaces
that we ship. You will notice that any Sun manpage contains an "Attributes"
section which should highlight to the user whether or not they should
consider using (e.g. linking against) any given interface.
Within Sun, teams who are responsible for including Open or Free Software
in Solaris (GNOME, evolution, mozilla, others) have had difficulties
working with the interface stability process. To fix these problems, the
review process will have to evolve. This evolution could be easier if
there is also interest from the Free/Open Software community.
Therefore, within Sun there are two kinds of free software. The
first kind is software that meets reasonable interface stability
requirements well enough to feel comfortable assigning them a Stable
classification.
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.
Therefore, if a Free/Open Source project wants to get "into"
Solaris/OpenSolaris and receive that exposure, they should see the
value in meeting such requirements. Aside from exposure, having clear
and effective interface documentation is obviously a good best practice.
I am currently working with the GNOME community to try and get a better
handle on what Stability means, and to encourage the GNOME community
to strengthen their interface documentation on the live.gnome.org Wiki.
Interface documentation requirements are included in this document, and
would apply to any project wanting to be included. You can read more
here:
http://live.gnome.org/InterfaceSpecification
Your statement of how things should work matches my
understanding of how things ought to work in the *long* term, but we have
a lot of short- and medium-term work to do before we get there, and much
of that work may be somewhat challenging.
Like what? I believe that the first step to getting to where you
want to be is to try to get there right now. Assuming that it can't
be done just because it seems like a big change is a non-starter.
We won't find out until we try.
What exactly is blocking us from
creating a directory containing ksh93 code and making it the
current ksh for OpenSolaris?
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.
To make things interesting, Sun realizes that it's review process will
need to evolve to work better with Free Software. So it would be good
if people from outside of Sun were also interested in working with us
to figure out how to make this process work best. In the past, ARC
has said that they would welcome review processes initiated from
someone outside of Sun, and although there have been some Solaris
interface reviews that have involved free software developers as
participants, there has not yet been one initiatied from someone
outside of Sun. Figuring out how to make this process work would
probably ease things for adoption in OpenSolaris. The process will
probably become slow and cumbersome if Sun can't find ways to get
free software developers involved with interface stability concerns.
So we need to recognize that the
development processes for Solaris in the past to a large extent continue
into the present and can only change so quickly in the near future.
Why?
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.
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.
The second is that you sound[1] awfully inflexible. While it is good
to have
such noble goals, given where we are, being too rigid in the short
term may
not be a Good Thing. So I would encourage flexibility and
open-mindedness
as we try to move from the dark past thru the dim present to the
(hopefully)
bright future.
My participation in OpenSolaris is conditioned on a number of
statements by Sun regarding the nature of this project. If those
statements are false, my participation will end quite abruptly.
You may consider that to be inflexible. I consider it to be simple
time management -- I have better things to do than convince a
recalcitrant and conservative organization to adhere to its own
press releases.
OpenSolaris is intended to be a collaborative project. In order
to collaborate with the rest of the world, future progress has to
be made in public, using public tools, on public work products.
Any code that is not open source is dead code that needs to be
replaced, and the way to do that is by creating communities with
live code that can be worked on in public. The only code in
OpenSolaris is open source code. Determining what parts of that
code are actually used by proprietary distributions like Solaris
is not our community's responsibility.
The CAB has been asked to create a governance process in which
collaboration can thrive. While there are several ways we could
approach such a process, none of them involve creating a state
wherein Solaris business decisions determine what can or cannot
go into OpenSolaris, since that is not collaboration.
Different OS distributions have their own processes, and it is not
unreasonable to expect OpenSolaris contributors to fit within a
reasonable framework. People complain about Debian restrictions
often, for example. It is likely that many Free Software
developers will likewise complain about OpenSolaris' processes
around interface stability.
As I've mentioned before, the biggest problem is that Sun's
current interface review process is done in an internal fashion,
so figuring out how the process will work for OpenSolaris is
a challange. The fact that there isn't a website somewhere
that says "do steps A, B, and C" is a big stumbling block, and
leading to a lot of chatter around this topic.
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.
2) Help us work through an interface review process to get the
default ksh upgraded. This might be a bit time-consuming, even
if the ksh documentation is good, but it would be a great way
to be involved with creating a new process for getting Free
Software developers involved with OpenSolaris, and with
being involved with defining a good process that works.
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.
So, this all begs the question, why isn't Sun making more of an
effort to define a workable OpenSolaris process for interface
review. There should be something on the http://www.opensolaris.org/
website addressing this topic, even if it just says "We are
working on figuring it out. Here are the difficulties. Help us."
In order for OpenSolaris to be collaborative, we really need to
spell this out.
Hopefully this email highlights some of the work that we're doing
to improve things with the GNOME project, and this might be helpful
in figuring out a general process.
Brian
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
