[stop, stop, you are bringing out the verbose monster in me!]
Roy T. Fielding wrote:
BUT THAT IS THE WHOLE POINT OF THIS DISCUSSION!
I don't operate under Solaris constraints.
OpenSolaris is NOT under the same constraints as Solaris
because ... thus have no influence over Jörg's desire to provide a
future OpenSolaris version of ksh that is based on ksh93.
I think you are overlooking a very important distinction.
The question on the table is "how should the master workspace/cvs tree
for OpenSolaris be managed", and not "how should forks, clones and other
second order derivatives be managed".
*ALL* of your examples are of these 2nd order "forks". And I agree with
you that it is not my place (nor Sun's, given the terms of the CDDL) to
dictate what you or they can or can not do with those forks. If you want
to fork off your own copy of OpenSolaris and follow your own muse, go ahead.
But, when it comes to putting your changes back into the source tree called
OpenSolaris, as a member of the OpenSolaris community, not only do I care
passionately about it, I am taking a very vocal and active role in trying
to define the constraints in the way I think is best. Yes I am biased, Yes
I work for Sun, and No, I'm not doing this or saying this because someone
"told me to push Sun's position". Unless you count that I've applied this
same passion internal to Sun to Sun's development process, and so Sun's party
line is in some small way a reflection of my efforts. (Ok, only the bugs
and warts. There are lots of others who should get whatever credits there
are to go around).
Today, the rules for what can go into the gate and the process for getting
it into the gate are still being defined - in good part by this discussion
and others like it. At some point soon, the process will start to change,
to incorporate the results of these discussions. And when the changes are
complete, the community (with both Sun and non-Sun people involved) will
be able to play all the roles in that process.
At that point, I believe we will have the following:
The CAB will have the authority to, and the responsibility of,
deciding which branches of OpenSolaris (aka consolidation versions)
it wishes to formally charter. Like all authority, it can be
delegated as needed.
Anyone will be allowed to fork copies off of these branches,
to evolve as they see fit, but those forks can not be called
"OpenSolaris". There will be a formal, defined process to follow
if you want your changes to be allowed back into OpenSolaris.
If you wish to be a part of the OpenSolaris community, you will be
expected to understand and follow some set of core values. Conversely,
the community will enforce those values and tend to reject proposals
that do violence to them.
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.
Whether or not we create a project within an OpenSolaris
community to tackle a given task is completely independent
of any interface constraints.
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.
-John
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
