John:
I hope that:
One of those core values will be "backwards compatibility is a
constraint,
not a goal". This implies that it is seen as a feature (and not a bug)
that there is no Major version development branch following the
current production branch.
I very much agree that interface stability and backwards compatibility
is one of the things that makes Solaris (and hopefully OpenSolaris)
a great operating system. Creating a framework for OpenSolaris to
integrate code in ways that ensure interface stability is a great
thing.
However, I see a lot of problems with the approaches that seem to be
evolving out of this discussion. For one thing, it seems that we
are suggesting that OpenSolaris should be bound to interface
stability issues for non-free interfaces found in Solaris. The ksh
example is a good one. How can OpenSolaris be made into a usable
operating system if the only way to "fill the gaps" is to create
what you are calling a "2nd order fork".
While it is certainly reasonable for a project to make and abide by
a stability promise in order to get into OpenSolaris, it is not
reasonable to expect that the Free Software community will spend
time re-implementing old interfaces just to have something like
ksh on the system. .
It isn't clear to me how the Free Software community will even have
a reasonably chance of getting things right if we expect them to
be bound to non-free Solaris interfaces. Is Sun prepared to
enumerate and document such expectations to the OpenSolaris
community?
It seems to make more sense to allow the OpenSolaris community
to add the reasonable free software replacement for such
components to OpenSolaris. Of course, it is reasonable to
expect that they will have to make stability promises and abide
by them to get them into OpenSolaris. Such bits should not need
to conform to non-free Solaris interfaces.
This probably means that such new bits of OpenSolaris will eventually
become SunOS 6. After all, the last time there was a major release
of Solaris was in the stone age, I mean the early 90's, and if Sun
believes that that the evolution of OpenSolaris will not cause a
major release down the pike, I think Sun has its head in the clouds.
This is a dramatic change, and will likely warrant some significant
interface impact.
Obviously SunOS 6 will be backwards compatible with SunOS 5 for
those components that Sun contributed into OpenSolaris, so SunOS
5 can continue to take new code from OpenSolaris for these pieces.
In other words, the interface breakages between SunOS 5.0 and 6.0
should only be those bits to "fill in the gaps" to make a
reasonable free operating system.
At some point, migrating to 6.0 and having a more usable free
software stack will likely become the right decision. It will
likely be less a headache than the SunOS 4-5 transition since
OpenSolaris will serve as a beta-test for the new interfaces
and issues will get resolved in OpenSolaris before Sun would
pull them into a SunOS 6.
This seems a more workable model to me, than expecting the
community to figure out how to get things into OpenSolaris without
breaking Solaris interfaces that don't exist in OpenSolaris.
You are advocating starting off the OpenSolaris community on a track that
immediately abandons this core value. I disagree (obviously), and instead
advocate keeping the core value, and leaving the question of creating a
new major branch to the point in time where we find something that - in
our community's considered opinion - can not be done under our current
constraints.
Opening Pandora's box and intentionally throwing away one of Solaris's
key features seems extremely shortsighted, not to mention
counterproductive.
The only thing we need to agree
on as a community is what the version numbers mean, and thereby
allow integrations like Solaris to choose which product versions
to include in which release.
In addition, we obviously need to agree on a set of guiding principles and
core values.
I very much agree, but it seems just backwards to try and bind
OpenSolaris to Solaris constraints. Instead OpenSolaris should
be free to define its own constraints in areas where there is
no free alternative.
Especially when the Solaris rules are buried in ARC cases which
are not yet visible to the OpenSolaris community. Refactoring
all ARC case information so it is usable by the OpenSolaris
community is probably not a reasonable task. Are we going to
expect the OpenSolaris community, for example, not to break
"contract private" interfaces between two Solaris modules?
Replacing one component with a free alternative may meet all
public/Stable interface requirements, but break things badly
on Solaris due to private contract interfaces that the
OpenSolaris community wouldn't even know about.
It seems more reasonable for OpenSolaris to set the stage for
interface change, and Solaris can adopt the interfaces that
make the most sense for Sun customers, just like any other
distribution that might use OpenSolaris. If this means
Sun rips out ksh93 and puts back in ksh88, why should that
be a big deal.
On a different topic, I can't believe that we didn't include
the manpages in OpenSolaris. Considering that the attributes
section of the manpages is where interface stability is
defined, how can we expect the OpenSolaris community to know
what needs to be kept stable without the manpages. This
seems a gross oversight.
Brian
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
