John Plocher [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
Why do you believe this?
ksh88 vs ksh93 deltas are described as features or improvements by the
ksh93 maintainer.
ksh88 vs pdksh deltas are described as bugs by the pdksh maintainer.
Why do you believe that pdksh makes less
Joerg Schilling wrote:
Why do you believe this?
ksh88 vs ksh93 deltas are described as features or improvements by the
ksh93 maintainer.
ksh88 vs pdksh deltas are described as bugs by the pdksh maintainer.
Why do you believe that pdksh makes less problems than ksh93?
The potential
[EMAIL PROTECTED] wrote:
Quite; the particular case of ksh is a difficult one; while I don't
think there are many people writing products based on ksh script
(I'd certainly hope there aren't any), scripts are often written
by system administrators and breakage is bad.
Similar to what Sun did
John Plocher [EMAIL PROTECTED] wrote:
Change of perspective
Are we all confusing the Consolidation called ON that lives
under the OpenSolaris banner with the whole set of potential
consolidations? Just because the ON consolidation is saddled with
compatibility issues with the closed stuff
Bill Sommerfeld [EMAIL PROTECTED] wrote:
in the specific case of ksh88, it may turn out to be the case that pdksh
is close enough that the known delta is just a few bug fixes away -- a
small-scale project rather than a major undertaking like rewriting it
from scratch...
Why do you believe
Alan Coopersmith [EMAIL PROTECTED] wrote:
The rules we've set up in Solaris allow us to do a large amount,
even incompatible change, without going to a new major release.
It would probably have to be something as fundamental as libc changing
incompatibility and not offering an old version to
On Tue, 2 Aug 2005, Joerg Schilling wrote:
The most important thing people need to understand is that
adding something that is closed source and cannot be redistributed
or ported to other (new) platforms is a deviation from OpenSolaris.
[ ... ]
This ties back to my message yesterday on this
JL == James Lick [EMAIL PROTECTED] writes:
JL Move current ksh to ksh88, add ksh93, and make ksh a link to ksh88.
JL Include a script to change the link to/from ksh88 or ksh93 so people
JL can configure the default to taste easily. In a future release the
JL link would point to
John:
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.
On Sat, 2005-07-30 at 19:11, John Plocher wrote:
In as much as we can follow Path 1 or 2A, the relationship between
Solaris and OpenSolaris is easy. Obviously, this includes
the forwards compatibility with Solaris.Future as well as that
of Solaris.Historical and other OpenSolaris derivatives.
Brian Cameron wrote:
I think it is just a matter of time before we find a necessary
component that isn't in OpenSolaris that we can't include for
licensing reasons, and something nobody is interested in rewriting.
When that time comes, it will be necessary to more look at SunOS6
as a solution.
Alan Coopersmith wrote:
For ksh, we could under the current rules do a variety of things:
- Add ksh93 as /usr/bin/ksh93 - simple, easy, no problems, and leave
both ksh88 and ksh93 in Solaris, with only ksh93 in OpenSolaris.
- Announce at least a year before the next minor release that we
At this point, it is clear you guys were not paying attention
to the contents of the thread. The disagreement is over the
community having the ability to work on a branch that is not
stable. All of the Solaris releases would be on a stable branch
that has the exact same interface stability
On Sun, 2005-07-31 at 06:46, [EMAIL PROTECTED] wrote:
No; I don't think that, though I'd expect much of the unstable
work not to happen on OpenSolaris .org
actually, I'd hope that opensolaris.org and/or genunix.org would provide
some way to publish/host work-in-progress (distinct from stuff
On Sun, 2005-07-31 at 06:46, [EMAIL PROTECTED] wrote:
No; I don't think that, though I'd expect much of the unstable
work not to happen on OpenSolaris .org
actually, I'd hope that opensolaris.org and/or genunix.org would provide
some way to publish/host work-in-progress (distinct from stuff
Roy T. Fielding wrote:
On Jul 29, 2005, at 6:12 PM, Al Hopper wrote:
That's what I thought originally, but a lot of the posts I have seen
are emphasizing the business decisions made by an ARC rather than
the technical review.
Where do you see this?
When a choice is made to work on a major
On 7/29/05, Roy T. Fielding [EMAIL PROTECTED] wrote:
I don't want to repeat the discussion we just had all over again.
I think my position is pretty clear from what I have written
already.
Well, I don't agree with what you say. I do not and have not ever had
an affiliation with SUN beyond
No it's not absolute rubbish - and describing it as such does a great
dis-service to those talented engineers who have worked on it. And to
those that understand it.
Quite; the particular case of ksh is a difficult one; while I don't
think there are many people writing products based on ksh
At this point, it is clear you guys were not paying attention
to the contents of the thread. The disagreement is over the
community having the ability to work on a branch that is not
stable. All of the Solaris releases would be on a stable branch
that has the exact same interface stability
Brian Cameron wrote:
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
Hello Roy,
Friday, July 29, 2005, 6:09:16 AM, you wrote:
RTF I am telling you, point blank, based on both my experience within
RTF the open source community and my research background in software
RTF architecture, that OpenSolaris will fail to achieve the goals set
RTF by Sun executives if you
Brian Cameron [EMAIL PROTECTED] wrote:
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
On Jul 29, 2005, at 6:12 PM, Al Hopper wrote:
That's what I thought originally, but a lot of the posts I have seen
are emphasizing the business decisions made by an ARC rather than
the technical review.
Where do you see this?
When a choice is made to work on a major branch or not.
I don't
On Thu, 28 Jul 2005, Roy T. Fielding wrote:
On Jul 28, 2005, at 2:46 PM, Bryan Cantrill wrote:
For an operating system, the constraints of existing interfaces are a
_technical_ problem, _not_ just a business problem.
That is absolute rubbish. A technical problem is something for which
On Thu, 28 Jul 2005, Shawn Walker wrote:
On 7/28/05, John Plocher [EMAIL PROTECTED] wrote:
[stop, stop, you are bringing out the verbose monster in me!]
snip
You are advocating starting off the OpenSolaris community on a track that
immediately abandons this core value. I disagree
Which is exactly how things had been working in practise inside Sun.
That's what I thought originally, but a lot of the posts I have seen
are emphasizing the business decisions made by an ARC rather than
the technical review.
The only real difference with OpenSolaris ARCs should be that
On Thu, 2005-07-28 at 14:38, Roy T. Fielding wrote:
That's what I thought originally, but a lot of the posts I have seen
are emphasizing the business decisions made by an ARC rather than
the technical review.
ARC is all about the technical architecture and almost always doesn't
get involved
On Jul 28, 2005, at 2:46 PM, Bryan Cantrill wrote:
For an operating system, the constraints of existing interfaces are a
_technical_ problem, _not_ just a business problem.
That is absolute rubbish. A technical problem is something for which
a technical solution can be created to resolve the
Roy ... a lot of the posts I have seen are emphasizing the business
Roy decisions made by an ARC rather than the technical review.
Bryan For an operating system, the constraints of existing interfaces
Bryan are a _technical_ problem, _not_ just a business problem.
Roy That is absolute rubbish...
Roy == Roy T Fielding [EMAIL PROTECTED] writes:
Roy On Jul 28, 2005, at 2:46 PM, Bryan Cantrill wrote:
For an operating system, the constraints of existing interfaces are a
_technical_ problem, _not_ just a business problem.
Roy A technical problem is something for which a technical solution
On Wed, Jul 27, 2005 at 06:08:12PM -0700, Roy T. Fielding wrote:
The latter constraint of requiring a commit be complete is
just as true for collaborative open source projects as it is for
Solaris. Most open source projects are distributed on several
orders of magnitude more platforms than
On 7/28/05, John Plocher [EMAIL PROTECTED] wrote:
[stop, stop, you are bringing out the verbose monster in me!]
snip
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
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
On Jul 25, 2005, at 4:20 PM, John Plocher wrote:
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
Roy I have been asked, by both the CAB members and Sun execs, to
Roy propose a governance process for collaborative open source
Roy development. Non-collaborative development is not considered a viable
Roy option given the competition and relative success of collaborative
Roy open source projects.
35 matches
Mail list logo
