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 believ
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 reacti
Bill Sommerfeld <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-02 at 13:04, Joerg Schilling 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 maj
> "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 wou
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 t
On Tue, 2005-08-02 at 13:04, Joerg Schilling 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...
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 vers
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 bel
John Plocher <[EMAIL PROTECTED]> wrote:
>
>
> 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 does not mea
[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
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
On Sat, 30 Jul 2005, Roy T. Fielding wrote:
> 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 branc
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.
I
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 derivat
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. H
>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 s
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 th
>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 a
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 requi
>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
>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
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 b
On Jul 29, 2005, at 7:21 PM, Al Hopper wrote:
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.
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!]
>
> > You are advocating starting off the OpenSolaris community on a track that
> > immediately abandons this core value. I disagree (o
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 w
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
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 1:34 PM, Darren J Moffat wrote:
> > On Wed, 2005-07-27 at 18:08, Roy T. Fielding wrote:
> >> Alternatively, OpenSolaris could give development autonomy to the
> >> communities, wherein technical development, discussion of
> >> alter
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
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 yo
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 28, 2005, at 7:30 PM, John Plocher wrote:
[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 .
John Plocher wrote:
... 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.
Hmm, this obviously shouldn't be taken as a legal position on the
the terms of the CDDL, which does, in fact, have something to say
about what you
On 7/28/05, John Plocher <[EMAIL PROTECTED]> wrote:
> [stop, stop, you are bringing out the verbose monster in me!]
> 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 v
[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 p
On Jul 28, 2005, at 5:13 PM, John Beck wrote:
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
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 t
> "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 tech
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 rubbis
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
[caution, long reply ahead, no major disagreements, just some minor
misunderstandings and _a_lot_ of examples, explanation and rationale.]
Roy,
Thanks for taking the time to contribute to this discussion. I hope
that together we all can build a shared value system that will be the
basis for cre
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
> >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 b
On Jul 28, 2005, at 1:34 PM, Darren J Moffat wrote:
On Wed, 2005-07-27 at 18:08, Roy T. Fielding wrote:
Alternatively, OpenSolaris could give development autonomy to the
communities, wherein technical development, discussion of
alternatives,
getting it to work, and testing can all take place i
On Wed, 2005-07-27 at 18:08, Roy T. Fielding wrote:
> Alternatively, OpenSolaris could give development autonomy to the
> communities, wherein technical development, discussion of alternatives,
> getting it to work, and testing can all take place independent of
> any ARC review. ARC review isn't n
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 proje
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 tec
48 matches
Mail list logo
