John:
How is this ARC review process going to work with the community? I think
it will become burdened if the core values of interface stability are not
shared with the Free/Open Software community.
In order to go through an interface review, the following information is
necessary:
+ Interface documentation.
+ Each interface which is imported or exported needs to be assigned
a stability level. To do this an interface taxonomy must exist
somewhere and terms like "interface" need to be defined. A
common language needs to exist.
+ How does versioning change when stable interfaces change (e.g.
libraries).
+ Are accepted standards (UNIX file installation locations, etc.)
followed.
+ If a proposal suggests replacing an existing interface, any
incompatibilities or issues need to be higlighted in the
documentation.
+ If something exists in Solaris but not OpenSolaris (like ksh)
and someone proposes putting something in OpenSolaris that is
incompatible with Solaris, how is this managed.
+ Recommendations about how to go about preparing documentation.
For example, the gtk-doc tool now allows users to specify stability
levels for interfaces.
+ In Solaris, we have SFW packages which contain free software
that does not contain any interfaces with guarantees. I assume
there will be something similar in OpenSolaris. How is the
process different in this case, and how does someone from the
Free/Open software community know what approach makes the most
sense.
+ I'm probably forgetting some things.
I realize that any project that wishes to get into OpenSolaris must
have a sponsor via [EMAIL PROTECTED] It would probably
be better if the Free/Open Software community could come to the sponsor
with any such documentation already in place.
Ideally, Free/Open Software projects should see the value in having
solid interface documentation that follows good best practices.
OpenSolaris should be doing more to encourage the Free/Open Software
community to follow better best-practices.
Shouldn't information of this nature also be visibile on the CAB
website?
http://www.opensolaris.org/os/community/cab/
Basically a "How-To" guide for getting software into OpenSolaris?
Brian
> 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
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
