> Keith and Roy's conversation about ksh...
Keep in mind the "traditional Sun/Solaris development model" that we are trying
to seed our community with:
Germinate an idea into a plan,
Commit to that plan from both resource and technical perspectives
(do we _want_ to do it? and
is this the _best_ way to architect it?)
Develop/implement to that plan
Integrate the result into the "FCS all the time" shared source base
How does this differ from "other" FOSS projects? Primarily in the
proactive nature of the "commit to a plan" before starting, and
"requiring that a project be complete" before allowing integration.
The former is simply good software engineering - know what you want
before you start hacking; the latter helps us avoid the reactionary
integration fire drills that often accompany "not ready for prime time"
putbacks/commits.
I can imagine two different proposals coming out of this discussion:
A) We should develop an extension to ksh93 that allows it to be used
as a "Stable" replacement for ksh88 in places where backwards
compatibility is required (i.e, such as when invoked as /bin/ksh)
while exposing all the latest features when compatibility is not
required (such as when it is involved as /bin/ksh93). This new
shell would expose the following interfaces:
/bin/ksh Stable
/bin/ksh93 Stable
or
B) We should make an incompatible change to the existing Stable ksh
interfaces provided by a binary-only closed source component. This
proposal would replace the existing ksh (ksh88) with an unmodified
ksh93. This new shell would expose the following interfaces:
/bin/ksh (ksh88) Obsolete/Removed (was Stable)
/bin/ksh (ksh93) Stable
If this were an ARC review, one of the proposals would be formally
submitted for review and commitment. As the discussion of the merits
and risks of the proposal progressed, I would hope that the core value
of "avoiding gratuitous incompatible changes to Stable interfaces"
would be in everyone's mind. After the dust settled and a formal
opinion was rendered, I would expect the following results:
Proposal A: Approved for a minor release of OpenSolaris/ON
-or-
Proposal B: There are three possible outcomes, of which B.3 is
the most likely:
B.1) Denied because of the incompatibilities, or
B.2) Approved for release in a Major incompatible
release
of OpenSolaris/ON (at Sun, such a release could be
expected to happen soon after hell froze over :-)
It may be that the CAB/community might decide to
go down this route; I hope we don't.
B.3) Approved for a minor release of OpenSolaris/ON
with a
"Technical Change Required" to the spec to provide
a
compatibility mode, such as in Proposal A.
Continuing this "model the expected behavior" example, now that we have
a committed plan, what would we do next? One possibility:
Create a teamware child workspace (or CVS branch or ...)
Gather a group of interested developers together to work
on this project
Seed this workspace with the ksh93 sources
Get it to work
Start building in the "dual mode" behavior
Develop - Test - Iterate... until complete,
Request permission to Integrate the changes back into OpenSolaris
Integrate/Putback/Commit...
When looking at this discussion in this light, I don't think that Keith
and Ray are that far apart - both want the same results in the end:
Reduce the quantity of closed-source that is required to make Open
Solaris usable to zero,
Improve the features in Open Solaris, and
Don't screw it up in the process.
-John
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
