Roy T. Fielding wrote:
Er, no offense,
None taken.
Note that I wasn't saying that the installer (person) would never
wish to be able to perform developer tasks like building from source
to produce an installation. I agree that the ability to build everything
is important - to developers and to people who need visibility into the
developer's world. My point was that not all installers need (or want)
that visibility, and that assuming that all installers were developers
tends to[1] cause conceptual blind spots.
I also wasn't saying that source based systems don't have the concept of
an ABI. Rather, I was saying that, in general[1], processes based on the
presumption of "build the entire system" tend to not detect changes that
are source level compatible but still result in binary incompatibilities.
Combine this with an attitude that tends to be reactive ("build the entire
system from scratch before installation so that they *know* the build
system works") and you get API's that are intended to be stable, rather
than ABI's that are demonstratably so. This is the (sometimes subtle)
difference between a goal and a constraint.
------
[1] All generalizations are flawed.
> other groups produce major versions
Yes, the frequency of major releases is tightly tied to this whole
discussion - IMHO, major releases are undesirable in systems where
predictability and stability are key requirements.
Major releases are a poor way to manage innovation because they are too
course grained and unconstrained. They simultaneously give no indication
of what has changed and allow indeterminate change.
In other words, it helps nobody when you misleadingly set expectations
today by saying that something will be Stable when you know full well
that you are going to change it tomorrow in a major release.
In these discussions about OpenSolaris, two key open issues are
1) What are all the stability promises that have been made for Solaris?
and
2) What is the relationship of OpenSolaris to those promises?
Many of us are working on publishing the former; this discussion is part of the
search for the latter.
I think we both are focusing on the "exception case", where an historical
stability promise does not match the actual or desired stability behavior.
This can happen when features are introduced with "too high" of a stability
promise, as well as when it is "too low". "Too low" is easy to fix, because
raising expectations is a compatible change :-)
"Too high" is more of a problem.
One common case is when you wish to *remove* some piece of the
system - effectively lowering its stability promise to Obsolete,
and after a bit, removing the bits from the system. Since Solaris
has shied away from major releases because they are considered to be
too risky, but it still has a need to get rid of obsolete stuff, we
have developed what we call the EOF (End Of Feature) process to allow
us to make limited and controlled "incompatible changes" to Solaris
without a major release. I expect that such a process would prove
useful in the OpenSolaris development world as well, even if the
things that motivate its use may change.
Other situations are handled on a case by case basis as part of
the ARC review process; impact, mitigation, transition plans, etc
all play a part in the discussion. Some few times the answer is
yes, downgrade the interface or make the incompatible change; most
other times it is no, go find a way to live up to the promises we
made. Some reasons we might allow such a change include
1) *Must* change the interface to close a security hole or
data corruption bug. The vulnerability is inherent in the
interface and not just a vestige of the implementation.
2) Expected Change - to not make the change would be unacceptable
to the **vast** majority of our customers, because the
expectations have changed. An example of this is the
incompatible changes made to pcfs in response to Windows
moving away from 8.3, case insensitive naming to unrestricted,
case sensitive naming. Our customers would expect this
change, incompatible or not. Note that the customer
expectation must be very obvious to meet this criteria.
3) The world has moved on and there is believed to be very
near zero usage of the interface. This is rarely (ever?)
a reason to modify an interface, but occasionally it is
a reason to remove one.
4) The community and customer expectation has changed.
By not tracking the community, we are performing
a disservice to our customers.
Note that in all cases (except perhaps #3), these exceptions only
tend to be granted when there is no practical way to engineer around
the incompatibility.
> Don't use FOSS ... OpenSolaris is simply an open source project.
As I was discussing the history of _Solaris's_ development processes
in a context where the words I was using could be confused with other
open source contextual meanings, I felt the term added value.
-John
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
