On May 31, 2007, at 12:01 PM, Glynn Foster wrote:
1.4 Involvement
There is a strong intention for this to be a community grass roots
project, with open contribution. We hope for this project to be
consensus driven, though ultimately the project leads will need
to dictate
On May 31, 2007, at 1:40 PM, Brian Gupta wrote:
If this is an OpenSolaris activity, it will obey the Group voting
procedures documented in the constitution. There is no such thing as
a sole arbiter at OpenSolaris, period.
Check out the following text CNET article: http://tinyurl.com/ys7hb2
On Mar 6, 2007, at 5:52 PM, Keith M Wesolowski wrote:
The Charter gives the Community and the OGB the power to establish
processes and procedures that govern every aspect of development other
than assignment of copyright. The Constitution in no way limits the
OGB's ability to exercise this
On Mar 7, 2007, at 2:54 PM, John Rice wrote:
We discussed this with Alfred and whilst he had thought of your
suggestion, wanted to opt for a mozilla dtrace project hosted on
OpenSolaris and a general Opensolaris one hosted on
developer.mozilla. This will host the LiveConnect and A11Y work.
On Mar 7, 2007, at 3:02 PM, Keith M Wesolowski wrote:
On Wed, Mar 07, 2007 at 01:55:02PM -0800, Roy T. Fielding wrote:
Article VII delegates all such work to Community Groups. Article
VIII
Article VII delegates nothing. Nowhere does it assign powers to any
Community Group or require
On Mar 5, 2007, at 10:30 AM, Garrett D'Amore wrote:
I also think this is a good sign that the relationship between
Communities and Projects is not well understood by all participants.
There are times it hasn't been at all clear to me, at least.
Perhaps getting an endorsing community needs to
On Mar 5, 2007, at 2:00 PM, Keith M Wesolowski wrote:
On Tue, Mar 06, 2007 at 09:55:37AM +1300, Glynn Foster wrote:
But there's absolutely no consistency with that. There's no
guidelines or best practices of how to apply the membership. If one
community's interpretation of the process is
The first day that the CAB met, almost two years ago, we talked about
all of the things that OpenSolaris needed to do to become successful.
Central to that discussion were three principles:
1) everyone needs to work on a common version control system
2) everyone needs to use a common issue
On Sep 7, 2005, at 4:12 AM, Simon Phipps wrote:
I find strident and over-assertive language distressing whichever
party is using it.
Irrelevant discussion on an open source project mailing list is
a cancer. It must be cut out to prevent those of us with high
email loads from unsubscribing.
On Aug 9, 2005, at 1:21 PM, [EMAIL PROTECTED] wrote:
After doing extensive work on making Solaris of the x86/x64 variety
more mobile
and trying to make it the laptop of choice withing Sun (not there yet,
but
in much better shape than some time ago), I'd like to propose the
On Aug 8, 2005, at 11:26 AM, John Plocher wrote:
As a result, Sun has developed a binary model (and here I do not
mean proprietary) that puts a premium on allowing things to maintain
compatibility - at a binary interface/API level - over time and over
release cycles.
Er, no offense, but
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 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 Jul 28, 2005, at 10:47 AM, Mike Kupfer wrote:
What about things like wifi drivers? I'm not an expert in the area,
but
I'm told that these drivers often contain a binary-only component (even
in Linux). It's apparently the result of US (FCC) regulatory
requirements on the wifi hardware.
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
On Jul 25, 2005, at 1:12 PM, Keith M Wesolowski wrote:
On Mon, Jul 25, 2005 at 03:48:52AM -0700, Roy T. Fielding wrote:
Why does it have to be 100% compatible? That is a serious question.
What breaks so bad that not having access to the source is considered
a viable solution?
100
for collaborative open source
development. Non-collaborative development is not considered
a viable option given the competition and relative success of
collaborative open source projects. I am hoping that the
development process team has kept that in mind.
Cheers,
Roy T. Fielding
On Jul 25, 2005, at 2:36 AM, [EMAIL PROTECTED] wrote:
They're shipping ksh93, which is open source. Solaris includes ksh88
(g I believe), which is not. We'd love to just upgrade, but they're
not 100% compatible.
We can certainly ship ksh 93 as /bin/ksh93.
It would be nice if we could
On Jul 25, 2005, at 9:52 AM, Keith M Wesolowski wrote:
What Alan was saying is that once a definitive list of differences
exists, it should be possible to implement a clean set of extensions
to ksh93 for backward compatibility; that implementation could then be
used by Solaris and included with
On Jul 25, 2005, at 10:43 AM, John Beck wrote:
The first is that all the mechanisms which you rail against are in fact
how things work now.
Yes. I intend to change that.
Your statement of how things should work matches my
understanding of how things ought to work in the *long* term, but we
I'd like to lead a desktop community focused on JDS. There's
absolutely
New Community Proposal focused on JDS ... gets my vote!
+1
Roy
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
21 matches
Mail list logo
