|
Replies:
32
-
Last Post:
Mar 7, 2007 7:03 PM
by: wesolows
|
|
|
Posts:
976
From:
Registered:
6/14/05
|
|
|
|
Re: Last Day for Nominations
Posted:
Mar 5, 2007 9:40 AM
To: Communities » cab » discuss
Cc: OpenSolaris » discuss
|
|
According to
""d) The election is being held per the OpenSolaris Constitution at:
http://www.opensolaris.org/os/community/cab/governance/
Attention Voters: In order to vote in the OGB elections you must be a
current Core Contributor. So please check your status at <URL:http://poll.opensolaris.org/> (click on the tab marked "Grants")"" I will be
_unable_
to vote, so I am sorry for all the noise.
While I am listed as (non-core-)contributor (to the PowerPC community), my main activities (Xorg@sparc, www.martux.org and http://opensolaris.org/os/project/qemu/leaders/) don't seem to count.
So I am by no means a "core contributor" - okay.
But someone who once did xyz IS ?? (I could name examples, but don't dare to)
At least do you now know, whom i _would_ have elected, if asked.
Thank you.
|
|
|
Posts:
5,829
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:02 AM
in response to: bochnig
|
|
Martin Bochnig wrote:
> While I am listed as (non-core-)contributor (to the PowerPC community), my main activities (Xorg@sparc, www.martux.org and http://opensolaris.org/os/project/qemu/leaders/) don't seem to count.
> So I am by no means a "core contributor" - okay.
The system for choosing core contributors is notably flawed in that
it only recognizes people working with Communities, not Projects or
distros. (For instance, Roland wasn't initially listed because
ksh93 is a Project, not a Community, and hasn't been affiliated with
any Community groups, yet he's one of the biggest contributors in
reality. Similarly, is your qemu project affiliated with any
community? If so, ask the leaders of that community why you weren't
included.)
For Xorg on sparc, I didn't list you because you have not yet
contributed anything to the X Community - but I was also very
unsure who to list when I generated the list of Core Contributors.
I'm sure once we get going on integrating your work into the X
Community, you'll count as a Core Contributor for X in the future,
but my understanding was Contributor status was supposed to reflect
past results, not future plans.
For your work on martux though, I think you would easily qualify for
one of the "Contributor at Large" spots, by mailing cab-discuss to
request such status.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:20 AM
in response to: alanc
|
|
On Mon, Mar 05, 2007 at 10:02:32AM -0800, Alan Coopersmith wrote:
> The system for choosing core contributors is notably flawed in that
> it only recognizes people working with Communities, not Projects or
> distros. (For instance, Roland wasn't initially listed because
This is not a flaw in the process but a flaw in the leadership of the
various Communities which should be following more closely the various
Projects which are or should be relevant to their areas of interest.
> ksh93 is a Project, not a Community, and hasn't been affiliated with
> any Community groups, yet he's one of the biggest contributors in
That's the defect - I'd like to know why the System Administration
Community, to name but one obvious example, has endorsed other
projects but not that one (it's their prerogative to make that choice,
but it seems as likely as not that it represents ignorance or
incompleteness rather than a conscious choice). One would expect that
with that recognition of the project itself would come contributor and
core contributor status for some or all of the major participants in
the project, provided that it is seen to have made significant
progress toward integration.
> reality. Similarly, is your qemu project affiliated with any
> community? If so, ask the leaders of that community why you weren't
> included.)
Exactly - that's the right place to start, not with the OGB and not
with the process itself. If the Community leaders are unresponsive or
don't appear to have any sound rationale for denying endorsement,
escalation to the OGB may be appropriate. The OGB should never force
a Community to endorse a Project; presumably the Communities are the
repository of technical knowledge and leadership and are expected to
make value judgments about the viability and desirability of ongoing
work. But denying endorsement by failing to maintain awareness of
relevant projects, because of personality conflicts, or for other
reasons not related to a project's technical merit is a problem well
within the OGB's mandate to address.
Suffice it to say that dealing with Community failure is one of the
deeper challenges facing the new OGB. Community leaders are advised
to put their houses in order sooner rather than later, and to seek
dissolution if adequate leadership cannot be found or a sensible
definition of scope cannot be agreed upon.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
5,829
From:
US
Registered:
3/9/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:25 AM
in response to: wesolows
|
|
Keith M Wesolowski wrote:
>> reality. Similarly, is your qemu project affiliated with any
>> community? If so, ask the leaders of that community why you weren't
>> included.)
>
> Exactly - that's the right place to start, not with the OGB and not
> with the process itself. If the Community leaders are unresponsive or
> don't appear to have any sound rationale for denying endorsement,
> escalation to the OGB may be appropriate. The OGB should never force
> a Community to endorse a Project; presumably the Communities are the
> repository of technical knowledge and leadership and are expected to
> make value judgments about the viability and desirability of ongoing
> work. But denying endorsement by failing to maintain awareness of
> relevant projects, because of personality conflicts, or for other
> reasons not related to a project's technical merit is a problem well
> within the OGB's mandate to address.
>
> Suffice it to say that dealing with Community failure is one of the
> deeper challenges facing the new OGB. Community leaders are advised
> to put their houses in order sooner rather than later, and to seek
> dissolution if adequate leadership cannot be found or a sensible
> definition of scope cannot be agreed upon.
In this case, I think it's still a follow-on of the poor initial setup
of Communities - instead of a Xen community, we should have a Virtualization
community with Xen & qemu projects.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Bryan Cantrill
bmc@eng.sun.com
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:28 AM
in response to: alanc
|
|
On Mon, Mar 05, 2007 at 10:25:28AM -0800, Alan Coopersmith wrote:
> Keith M Wesolowski wrote:
> >>reality. Similarly, is your qemu project affiliated with any
> >>community? If so, ask the leaders of that community why you weren't
> >>included.)
> >
> >Exactly - that's the right place to start, not with the OGB and not
> >with the process itself. If the Community leaders are unresponsive or
> >don't appear to have any sound rationale for denying endorsement,
> >escalation to the OGB may be appropriate. The OGB should never force
> >a Community to endorse a Project; presumably the Communities are the
> >repository of technical knowledge and leadership and are expected to
> >make value judgments about the viability and desirability of ongoing
> >work. But denying endorsement by failing to maintain awareness of
> >relevant projects, because of personality conflicts, or for other
> >reasons not related to a project's technical merit is a problem well
> >within the OGB's mandate to address.
> >
> >Suffice it to say that dealing with Community failure is one of the
> >deeper challenges facing the new OGB. Community leaders are advised
> >to put their houses in order sooner rather than later, and to seek
> >dissolution if adequate leadership cannot be found or a sensible
> >definition of scope cannot be agreed upon.
>
> In this case, I think it's still a follow-on of the poor initial setup
> of Communities - instead of a Xen community, we should have a Virtualization
> community with Xen & qemu projects.
I can't bring myself to utter "+1" -- a response that I put in the same
mental bin as "please remove me from this alias" -- but I agree with
Alan's sentiment...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,364
From:
US
Registered:
4/27/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:30 AM
in response to: alanc
|
|
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 be a prerequisite to
setting up a project?
-- Garrett
Alan Coopersmith wrote:
> Keith M Wesolowski wrote:
>>> reality. Similarly, is your qemu project affiliated with any
>>> community? If so, ask the leaders of that community why you weren't
>>> included.)
>>
>> Exactly - that's the right place to start, not with the OGB and not
>> with the process itself. If the Community leaders are unresponsive or
>> don't appear to have any sound rationale for denying endorsement,
>> escalation to the OGB may be appropriate. The OGB should never force
>> a Community to endorse a Project; presumably the Communities are the
>> repository of technical knowledge and leadership and are expected to
>> make value judgments about the viability and desirability of ongoing
>> work. But denying endorsement by failing to maintain awareness of
>> relevant projects, because of personality conflicts, or for other
>> reasons not related to a project's technical merit is a problem well
>> within the OGB's mandate to address.
>>
>> Suffice it to say that dealing with Community failure is one of the
>> deeper challenges facing the new OGB. Community leaders are advised
>> to put their houses in order sooner rather than later, and to seek
>> dissolution if adequate leadership cannot be found or a sensible
>> definition of scope cannot be agreed upon.
>
> In this case, I think it's still a follow-on of the poor initial setup
> of Communities - instead of a Xen community, we should have a
> Virtualization
> community with Xen & qemu projects.
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,458
From:
NL
Registered:
3/9/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 11:01 AM
in response to: gdamore
|
|
>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 be a prerequisite to
>setting up a project?
Perhaps our view of the world is too simplistic also; surely there
are projects which straddle many boundaries and projects which have
sub projects or communities which have special interest groups.
We need some form to organize, but it's not easy to see if there is
a proper simple model.
Casper
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,732
From:
Registered:
7/15/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 1:13 PM
in response to: casper
To: OpenSolaris » discuss
|
|
> Perhaps our view of the world is too simplistic also;
> surely there
> are projects which straddle many boundaries and
> projects which have
> sub projects or communities which have special
> interest groups.
Too simplistic?
When I read all of the comments here, I thought to myself:
"boy did you guys OVERCOMPLICATE it!!!"
Communities??? What??? Communities with Projects??? Who??? Where??? What??? Why??? How??? HUH?????...
Just leaves one scratching one's head in confusion.
It's real simple: if someone like Masayuki Murayama or Jurgen Keil or Roland Mainz can't be recognized as a core contributor, then something is very, very wrong with the current system, almost to the point of losing confidence in that system.
Projects is also a problematic criteria: a project might sound great, but deliver *zilch* or "vaporware". Whether a project is or is not deemed core or important for OpenSolaris should be a concensus.
Until then, a project is just a pretty description on opensolaris.org, and vaporware if nothing is delivered.
What that means is, in the absence of software being released from projects, who fixed how many bugs is what should be the criteria on who is a "core contributor" and who isn't. At least from the non-Sun side.
I'm all for engineering and processes, but let's keep it simple where we don't have to have it complex.
And the more I think about it, the more convinced I am that we should *DITCH* current criteria for what makes a contributor core one.
That should be a matter of direct democracy and a concensus among the whole OpenSolaris communitty. And we all know who fixed the most bugs and delivered the most contributions to OpenSolaris as far as non-Sun members go. Cold hard data is right here on opensolaris.org pages. All contributions are accounted for.
> We need some form to organize, but it's not easy to
> see if there is
> a proper simple model.
See above.
|
|
|
|
|
Posts:
142
From:
Newport Beach, California
Registered:
4/27/05
|
|
|
|
Re: Re: Last Day for Nominations
Posted:
Mar 6, 2007 2:24 PM
in response to: gdamore
|
|
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 be a prerequisite to
> setting up a project?
To be clear, the draft constitution does not allow projects to
exist outside the scope of a community group. I expect all of
the current Community and Project definitions to change as a result
once the constitution is ratified.
This election is the initial bootstrap process. The new OGB will
be responsible for reorganizing the communities into groups that
can govern themselves with somewhat less anarchic tendencies than
the current situation of having informal proposals result in the
allocation of resources.
....Roy
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,697
From:
US
Registered:
4/28/05
|
|
|
|
Re: Last Day for Nominations
Posted:
Mar 6, 2007 2:52 PM
in response to: fielding
|
|
On Tue, 6 Mar 2007, Roy T. Fielding wrote:
> ...
> ...
> This election is the initial bootstrap process. The new OGB will
> be responsible for reorganizing the communities into groups that
> can govern themselves with somewhat less anarchic tendencies than
> the current situation of having informal proposals result in the
> allocation of resources.
>
> ....Roy
I disagree that the resource allocation is big enough to be a key factor.
It's pretty small, I think.
Eric
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:33 AM
in response to: alanc
|
|
On Mon, Mar 05, 2007 at 10:25:28AM -0800, Alan Coopersmith wrote:
> In this case, I think it's still a follow-on of the poor initial setup
> of Communities - instead of a Xen community, we should have a Virtualization
> community with Xen & qemu projects.
Completely agree. Nothing precludes the formation of such a community
today under the existing process, followed immediately by the creation
of a QEMU project, endorsement, and grant of Core Contributor status
by the Community's new leaders. If such events transpire, I would
expect the Xen Community (acting jointly with the new Community) to
petition the OGB for coalescence under an agreement specifying the
leadership roles and status of contributorship grants and project
endorsements under the unified Community. I would also expect that
petition to incorporate a request that Xen be reclassified as a
Project. It seems more likely than not that the Xen Community would
not retain that status following a thorough review by the next OGB, so
there is little incentive for anyone to defer cleaning this up.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
820
From:
Registered:
4/27/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:44 AM
in response to: wesolows
|
|
On Mon, 5 Mar 2007, Keith M Wesolowski wrote:
> On Mon, Mar 05, 2007 at 10:25:28AM -0800, Alan Coopersmith wrote:
>
> > In this case, I think it's still a follow-on of the poor initial setup
> > of Communities - instead of a Xen community, we should have a Virtualization
> > community with Xen & qemu projects.
>
> Completely agree. Nothing precludes the formation of such a community
> today under the existing process, followed immediately by the creation
> of a QEMU project, endorsement, and grant of Core Contributor status
> by the Community's new leaders. If such events transpire, I would
> expect the Xen Community (acting jointly with the new Community) to
> petition the OGB for coalescence under an agreement specifying the
> leadership roles and status of contributorship grants and project
> endorsements under the unified Community. I would also expect that
> petition to incorporate a request that Xen be reclassified as a
> Project. It seems more likely than not that the Xen Community would
> not retain that status following a thorough review by the next OGB, so
> there is little incentive for anyone to defer cleaning this up.
>
Keith - I like your "Can Do" attitude. Yes there were mistakes made, yes
the OGB could have done better - but my (personal) attitude at the time
was to be as inclusive as possible and to err on the side of having little
or no barriers to the initial growth of the project.
On the other hand, we could have formed a commission, spent a bunch of
time hashing out a better Community/Project organizational tree ... and,
guess what, after a year it would have needed an overhaul anyway - simply
because of changes in technology and the natural evolution of OpenSolaris.
Keith has the right attitude and the right solution. Treat it just like
any other "bug" and work the *solution* going forward.
In the meantime, let's do everything possible, so that potential voters
and valuable contributors like Martin (Martux) Bochnig don't feel
disenfranchised or poorly treated.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. al@logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005
OpenSolaris Governing Board (OGB) Member - Feb 2006
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
511
From:
Registered:
3/9/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:40 AM
in response to: alanc
|
|
On Mon, 5 Mar 2007, Alan Coopersmith wrote:
[ ... ]
> In this case, I think it's still a follow-on of the poor initial setup
> of Communities - instead of a Xen community, we should have a Virtualization
> community with Xen & qemu projects.
And a Zones project. And a BrandZ project. A solaris-vmware forum.
Whatever. A first-contact point for people interested in virtualization.
A big second frome me for this idea of "umbrella communities", a little
bit more hierarchies than the current very flat setup would only do good.
Very similar considerations apply to e.g. Filesystems. Why need a ZFS
community, a NFS community, and one for UFS ? Why no "generic" umbrella
with specific subdivisions as projects ?
FrankH.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
516
From:
US
Registered:
6/14/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 11:09 AM
in response to: alanc
|
|
I agree that communities/projects should be organized better.
Octave
--- Alan Coopersmith <alan dot coopersmith at sun dot com> wrote:
> Keith M Wesolowski wrote:
> >> reality. Similarly, is your qemu project affiliated with any
> >> community? If so, ask the leaders of that community why you
> weren't
> >> included.)
> >
> > Exactly - that's the right place to start, not with the OGB and not
> > with the process itself. If the Community leaders are unresponsive
> or
> > don't appear to have any sound rationale for denying endorsement,
> > escalation to the OGB may be appropriate. The OGB should never
> force
> > a Community to endorse a Project; presumably the Communities are
> the
> > repository of technical knowledge and leadership and are expected
> to
> > make value judgments about the viability and desirability of
> ongoing
> > work. But denying endorsement by failing to maintain awareness of
> > relevant projects, because of personality conflicts, or for other
> > reasons not related to a project's technical merit is a problem
> well
> > within the OGB's mandate to address.
> >
> > Suffice it to say that dealing with Community failure is one of the
> > deeper challenges facing the new OGB. Community leaders are
> advised
> > to put their houses in order sooner rather than later, and to seek
> > dissolution if adequate leadership cannot be found or a sensible
> > definition of scope cannot be agreed upon.
>
> In this case, I think it's still a follow-on of the poor initial
> setup
> of Communities - instead of a Xen community, we should have a
> Virtualization
> community with Xen & qemu projects.
>
> --
> -Alan Coopersmith- alan dot coopersmith at sun dot com
> Sun Microsystems, Inc. - X Window System Engineering
>
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss at opensolaris dot org
>
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Systems Engineer
http://www.opensolaris.org/os/community/sysadmin/
http://unixconsole.blogspot.com
unixconsole at yahoo dot com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
_____________________________________________________________________________ _______
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
516
From:
US
Registered:
6/14/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 11:06 AM
in response to: wesolows
|
|
Hi,
Speaking as the leader of the Systems Administration community, I'd
have to say that the endorsement function is a manual process and
doesn't change any community processes. It's a totally manual process
where you select from a list of projects to endorse. I haven't updated
it in a long time and when I last did I just selected a bunch of things
that were of interest to what we were doing at the time. All it ends up
doing is creating a list with links. It doesn't reflect a formal
relationship or anything. As a matter of fact, I don't like where the
list ends up on the page:( And have thought about removing the items in
the list just because of that. It probably should do something more
functional, but it's just a way to link to projects.
Octave
--- Keith M Wesolowski <keith dot wesolowski at sun dot com> wrote:
> On Mon, Mar 05, 2007 at 10:02:32AM -0800, Alan Coopersmith wrote:
>
> > The system for choosing core contributors is notably flawed in that
> > it only recognizes people working with Communities, not Projects or
> > distros. (For instance, Roland wasn't initially listed because
>
> This is not a flaw in the process but a flaw in the leadership of the
> various Communities which should be following more closely the
> various
> Projects which are or should be relevant to their areas of interest.
>
> > ksh93 is a Project, not a Community, and hasn't been affiliated
> with
> > any Community groups, yet he's one of the biggest contributors in
>
> That's the defect - I'd like to know why the System Administration
> Community, to name but one obvious example, has endorsed other
> projects but not that one (it's their prerogative to make that
> choice,
> but it seems as likely as not that it represents ignorance or
> incompleteness rather than a conscious choice). One would expect
> that
> with that recognition of the project itself would come contributor
> and
> core contributor status for some or all of the major participants in
> the project, provided that it is seen to have made significant
> progress toward integration.
>
> > reality. Similarly, is your qemu project affiliated with any
> > community? If so, ask the leaders of that community why you
> weren't
> > included.)
>
> Exactly - that's the right place to start, not with the OGB and not
> with the process itself. If the Community leaders are unresponsive
> or
> don't appear to have any sound rationale for denying endorsement,
> escalation to the OGB may be appropriate. The OGB should never force
> a Community to endorse a Project; presumably the Communities are the
> repository of technical knowledge and leadership and are expected to
> make value judgments about the viability and desirability of ongoing
> work. But denying endorsement by failing to maintain awareness of
> relevant projects, because of personality conflicts, or for other
> reasons not related to a project's technical merit is a problem well
> within the OGB's mandate to address.
>
> Suffice it to say that dealing with Community failure is one of the
> deeper challenges facing the new OGB. Community leaders are advised
> to put their houses in order sooner rather than later, and to seek
> dissolution if adequate leadership cannot be found or a sensible
> definition of scope cannot be agreed upon.
>
> --
> Keith M Wesolowski "Sir, we're surrounded!"
> FishWorks "Excellent; we can attack in any direction!"
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss at opensolaris dot org
>
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Systems Engineer
http://www.opensolaris.org/os/community/sysadmin/
http://unixconsole.blogspot.com
unixconsole at yahoo dot com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
_____________________________________________________________________________ _______
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,914
From:
NZ
Registered:
6/16/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 12:55 PM
in response to: wesolows
|
|
Hi,
Keith M Wesolowski wrote:
>> reality. Similarly, is your qemu project affiliated with any
>> community? If so, ask the leaders of that community why you weren't
>> included.)
>
> Exactly - that's the right place to start, not with the OGB and not
> with the process itself. If the Community leaders are unresponsive or
> don't appear to have any sound rationale for denying endorsement,
> escalation to the OGB may be appropriate. The OGB should never force
> a Community to endorse a Project; presumably the Communities are the
> repository of technical knowledge and leadership and are expected to
> make value judgments about the viability and desirability of ongoing
> work. But denying endorsement by failing to maintain awareness of
> relevant projects, because of personality conflicts, or for other
> reasons not related to a project's technical merit is a pro**** well
> within the OGB's mandate to address.
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 easier for geting 'Core Contributor' status compared to another
community's process, then you're potentially going to get a weighted community.
No one wants that, it'll only lead to bitterness among the wider community.
While I can appreciate how it on a local level within the various OpenSolaris
sub-communities, so that you build up a web of trust when technical issues need
to be tackled, I'm still really struggling how it fits with the wider global
OpenSolaris community. It's very clear there are a number of
groups/individuals/whatever that don't have the same level of interest or
approach to detail that you do, Keith, and that worries the **** out of me.
Glynn
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
689
From:
GB
Registered:
5/18/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 1:37 PM
in response to: gman
|
|
On Mar 5, 2007, at 20:55, Glynn Foster wrote:
> Hi,
>
> Keith M Wesolowski wrote:
>>> reality. Similarly, is your qemu project affiliated with any
>>> community? If so, ask the leaders of that community why you weren't
>>> included.)
>>
>> Exactly - that's the right place to start, not with the OGB and not
>> with the process itself. If the Community leaders are
>> unresponsive or
>> don't appear to have any sound rationale for denying endorsement,
>> escalation to the OGB may be appropriate. The OGB should never force
>> a Community to endorse a Project; presumably the Communities are the
>> repository of technical knowledge and leadership and are expected to
>> make value judgments about the viability and desirability of ongoing
>> work. But denying endorsement by failing to maintain awareness of
>> relevant projects, because of personality conflicts, or for other
>> reasons not related to a project's technical merit is a problem well
>> within the OGB's mandate to address.
>
> 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 easier for geting 'Core Contributor' status compared
> to another
> community's process, then you're potentially going to get a
> weighted community.
> No one wants that, it'll only lead to bitterness among the wider
> community.
>
> While I can appreciate how it on a local level within the various
> OpenSolaris
> sub-communities, so that you build up a web of trust when technical
> issues need
> to be tackled, I'm still really struggling how it fits with the
> wider global
> OpenSolaris community. It's very clear there are a number of
> groups/individuals/whatever that don't have the same level of
> interest or
> approach to detail that you do, Keith, and that worries the ****
> out of me.
I think the OGB always assumed this would be one of the first areas a
new, elected OGB would want to work on. Just because the "membership"
mechanism is as it is for this bootstrapping process doesn't mean it
is either correct or that it is permanent. It is just there to get us
started.
S.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
844
From:
IE
Registered:
6/15/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 2:54 PM
in response to: webmink
|
|
Simon Phipps wrote:
>
> On Mar 5, 2007, at 20:55, Glynn Foster wrote:
>
>> Hi,
>>
>> Keith M Wesolowski wrote:
>>>> reality. Similarly, is your qemu project affiliated with any
>>>> community? If so, ask the leaders of that community why you weren't
>>>> included.)
>>>
>>> Exactly - that's the right place to start, not with the OGB and not
>>> with the process itself. If the Community leaders are unresponsive or
>>> don't appear to have any sound rationale for denying endorsement,
>>> escalation to the OGB may be appropriate. The OGB should never force
>>> a Community to endorse a Project; presumably the Communities are the
>>> repository of technical knowledge and leadership and are expected to
>>> make value judgments about the viability and desirability of ongoing
>>> work. But denying endorsement by failing to maintain awareness of
>>> relevant projects, because of personality conflicts, or for other
>>> reasons not related to a project's technical merit is a problem well
>>> within the OGB's mandate to address.
>>
>> 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 easier for geting 'Core Contributor' status compared
>> to another
>> community's process, then you're potentially going to get a weighted
>> community.
>> No one wants that, it'll only lead to bitterness among the wider
>> community.
>>
>> While I can appreciate how it on a local level within the various
>> OpenSolaris
>> sub-communities, so that you build up a web of trust when technical
>> issues need
>> to be tackled, I'm still really struggling how it fits with the wider
>> global
>> OpenSolaris community. It's very clear there are a number of
>> groups/individuals/whatever that don't have the same level of
>> interest or
>> approach to detail that you do, Keith, and that worries the **** out
>> of me.
>
> I think the OGB always assumed this would be one of the first areas a
> new, elected OGB would want to work on. Just because the "membership"
> mechanism is as it is for this bootstrapping process doesn't mean it
> is either correct or that it is permanent. It is just there to get us
> started.
But the current process has meant many people who have a high
commitment are being left out because
- they have not be following cab-discuss
- their core contributers of their community have not following the
cab-discuss process
But the more alienating factor is most likely to be the selection of
contributors is not transparent. Especially when one sees their peers
are not the list and they are not on the list.
At least when I was working on the membership committee of GNOME
foundation membership, there is a cohereant decision making process
which we at one stage was so firmly guarded, we even rejected Bruce
Perens (http://en.wikipedia.org/wiki/Bruce_Perens) on his first
application for membership. Bad, but at least consistent.
We certainly lacking consistency at this moment, let the emotion pass
and let hope the new OGB will work on this as their first primary goals,
promotion of membership.
-Ghee
>
> S.
>
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss at opensolaris dot org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 2:00 PM
in response to: gman
|
|
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 easier for geting 'Core
> Contributor' status compared to another community's process, then
> you're potentially going to get a weighted community. No one wants
> that, it'll only lead to bitterness among the wider community.
Yes, that's a valid concern, and in fact I noticed very early on that
we had this problem already. As of the last publication, the
communities have core contributor representation as follows:
4 academic
1 approach
9 arc
4 brandz
9 cab
9 desktop
5 documentation
4 dtrace
6 fm
5 i18n
2 immigrants
10 install
11 laptop
6 marketing
5 mdb
8 network
3 nfs
48 on
9 performance
4 ppc
5 smf
9 testing
23 tools
105 usergroup
3 x
15 zfs
6 zones
That is, almost 1/3 of all core contributors represent the user
groups, and another 15% are the ON CRT. Surely, you'd think, user
groups aren't the single most important activity we have going, more
than twice as important as anything else.
In truth, the problem we have today is not that some communities have
made it too easy to obtain core contributorship, or even that there is
no consistent guideline for awarding it. Simply put, the largest
problem is that some communities have done a good job of identifying
contributors and others have not. A secondary problem is that some
communities (without regard for their relative value) simply don't
have very many contributors. In the long run, this suggests that
per-Community representation may someday be needed a la the United
States Senate. In the short run, it suggests that some communities
are poorly organised and led, and those communities will be the ones
who are left without a voice, leaving interested parties to petition
for replacement or dissolution of those ineffective communities.
Until we have a sensible set of communities with clear and effective
leadership, I see little reason for the OGB to issue guidelines in an
effort to prevent communities from granting core contributorship too
easily. That problem will be better addressed after community
reorganisation.
> While I can appreciate how it on a local level within the various
> OpenSolaris sub-communities, so that you build up a web of trust
> when technical issues need to be tackled, I'm still really
> struggling how it fits with the wider global OpenSolaris
Likewise. A lot of this depends on exactly what role the OGB will
claim for itself. The proposed Constitution gives vast, dare I say
unconscionable, power to the OGB and to my way of thinking relies far
too much on the goodness of its members and the vigilance of the
electorate to ensure proper use of that power (rather than placing
stricter limits on the OGB but giving its members greater independence
to act within those limits). The requirement for such widespread and
intimate participation in government may well turn out to be a serious
handicap in a community in which many or most participants would
rather engineer software, especially if such an unbalanced situation
arises. That's doubly true given that, so far, the balance of power
is firmly against those who "just want to write code." If this
situation persists, the OGB may need to consider structural changes to
the Constitution, assuming it's ratified. What shape those changes
might take would depend on the nature of the imbalance and the
rulemaking areas into which the OGB chooses to wade.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,154
From:
US
Registered:
6/14/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 3:17 PM
in response to: wesolows
|
|
On 06/03/07, Keith M Wesolowski <keith dot wesolowski at sun dot com> wrote:
> have very many contributors. In the long run, this suggests that
> per-Community representation may someday be needed a la the United
> States Senate. In the short run, it suggests that some communities
> are poorly organised and led, and those communities will be the ones
> who are left without a voice, leaving interested parties to petition
> for replacement or dissolution of those ineffective communities.
This is something that has concerned me as well. Related to this
particular problem, I think, is also the perception of activity within
the OpenSolaris community as a whole. While having these "separate
communities" makes for a far better signal-to-noise ratio, it also has
the unintended side effect of making some communities appear vibrant
and alive while others do not.
While this may accurately reflect the activity of an individual
community, it can have some unintended consequences. One of those
unintended consequences is that it is much harder to perceive the
level of activity that is occurring within the OpenSolaris community
as a whole since the activity within each community is "filtered" to a
particular level.
With this in mind, it is not surprising, to me, that individuals are
left wondering about their status or role within the community. Some
individuals participate in many different communities on a frequent
basis, but never enough to be "recognized" in any individual one. As a
result, we may miss out on opportunities to recognise people that
bring great value to the OpenSolaris community as a whole because of
the reliance on individual community leadership to provide
recognition. Recent comments regarding "Projects" are a good example
of this particular scenario in my view.
I also completely support the idea of a unified set of contributors.
To me, a contributor is a contributor to the entire OpenSolaris
community and project, not just one part of it. Because of that, I
don't think that a status that affects the community as a whole
(voting, etc.) should be a status granted on a per-community basis. I
also think that listing people as "contributors" in some official
capacity for each specific community will only serve to embitter some
individuals. To me, almost every contributor contributes to every
"individual community" in an indirect fashion. Is the OpenSolaris
community not the result of all contributors instead of a specific
part?
> > On Tue, Mar 06, 2007 at 09:55:37AM +1300, Glynn Foster wrote:
> > While I can appreciate how it on a local level within the various
> > OpenSolaris sub-communities, so that you build up a web of trust
> > when technical issues need to be tackled, I'm still really
> > struggling how it fits with the wider global OpenSolaris
>
> Likewise. A lot of this depends on exactly what role the OGB will
> claim for itself. The proposed Constitution gives vast, dare I say
> unconscionable, power to the OGB and to my way of thinking relies far
> too much on the goodness of its members and the vigilance of the
> electorate to ensure proper use of that power (rather than placing
> stricter limits on the OGB but giving its members greater independence
> to act within those limits). The requirement for such widespread and
> intimate participation in government may well turn out to be a serious
> handicap in a community in which many or most participants would
> rather engineer software, especially if such an unbalanced situation
> arises. That's doubly true given that, so far, the balance of power
> is firmly against those who "just want to write code." If this
> situation persists, the OGB may need to consider structural changes to
> the Constitution, assuming it's ratified. What shape those changes
> might take would depend on the nature of the imbalance and the
> rulemaking areas into which the OGB chooses to wade.
I cannot possibly agree more with this statement. This only further
supports Stephen Lau's post about why the OGB shouldn't be intimately
involved in the day-to-day processes of the community (please read the
full blog post here:
http://whacked.net/2007/02/26/why-i-hope-the-ogb-wont-accomplish-much/).
As an example, I would like to see the OGB not have to be involved in
the recognition of contributors.
As far as the OGB's powers: I think that the OGB's powers should be
limited unless they are acting as an arbiter to resolve conflict, or
to help guide the community to a decision where there is deadlock.
I am heartened to see someone within SUN expressing these concerns
because it continues to prove that people within SUN care very much
about a genuine, vibrant community existing around this project. (Not
that I have ever been given reason to believe otherwise...)
--
"Less is only more where more is no good." --Frank Lloyd Wright
Shawn Walker, Software and Systems Analyst
binarycrusader at gmail dot com - http://binarycrusader.blogspot.com/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
689
From:
GB
Registered:
5/18/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 3:38 PM
in response to: swalker
|
|
On Mar 5, 2007, at 23:17, Shawn Walker wrote:
> I cannot possibly agree more with this statement. This only further
> supports Stephen Lau's post about why the OGB shouldn't be intimately
> involved in the day-to-day processes of the community (please read the
> full blog post here:
> http://whacked.net/2007/02/26/why-i-hope-the-ogb-wont-accomplish-
> much/).
> As an example, I would like to see the OGB not have to be involved in
> the recognition of contributors.
Indeed, I agree totally. And they didn't, it was left to the
Communities. The direct recognition process is an exception-handling
process.
> As far as the OGB's powers: I think that the OGB's powers should be
> limited unless they are acting as an arbiter to resolve conflict, or
> to help guide the community to a decision where there is deadlock.
This has been my consistent position throughout the OGB's tenure and
I believe that it's what the Governance says, as far as that's possible.
While it's gratifying to see all this interest in the governance, I
only wish it had been expressed several months ago when requested.
S.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: [cab-discuss] Re: Re: Last Day for Nominations
Posted:
Mar 6, 2007 7:38 AM
in response to: webmink
|
|
On Mon, Mar 05, 2007 at 11:38:46PM +0000, Simon Phipps wrote:
> Indeed, I agree totally. And they didn't, it was left to the
> Communities. The direct recognition process is an exception-handling
> process.
Yes; the volume of requests just makes it clear that we need a
higher-level exception-handling process for broken Communities (at
least).
> While it's gratifying to see all this interest in the governance, I
> only wish it had been expressed several months ago when requested.
You may recall that I expressed reservations about several aspects of
the proposed constitution during its formation. The overwhelming
decision of the Working Group at that time was that these concerns
could be addressed at an arbitrary later time in the form of
amendments (and the proposed constitution does indeed permit doing
so). That inherently means that these issues will have to be
addressed as they arise and with less time for reflection than the
year-plus period in which the current draft was produced. Issues are
now arising, and people are now taking interest. This pattern would
appear to be consistent with the Working Group's intent. It remains
to be seen whether the perceived urgency of resolving these issues
and/or the depth of thought given to them by the individuals concerned
will be conducive to solutions superior to those the Working Group
might have developed.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
142
From:
Newport Beach, California
Registered:
4/27/05
|
|
|
|
Re: Last Day for Nominations
Posted:
Mar 6, 2007 2:42 PM
in response to: wesolows
|
|
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 easier for geting 'Core
>> Contributor' status compared to another community's process, then
>> you're potentially going to get a weighted community. No one wants
>> that, it'll only lead to bitterness among the wider community.
>
> Yes, that's a valid concern, and in fact I noticed very early on that
> we had this problem already.
Some imbalances won't matter, since the community-wide elections
are very general anyway. However,
> 105 usergroup
is just a ridiculous number. 105 contributors, sure, but there is
no way that there should be that many *core* contributors. The core
contributors are the people who have made significant contributions
over a long period of time.
> Likewise. A lot of this depends on exactly what role the OGB will
> claim for itself. The proposed Constitution gives vast, dare I say
> unconscionable, power to the OGB and to my way of thinking relies far
> too much on the goodness of its members and the vigilance of the
> electorate to ensure proper use of that power (rather than placing
> stricter limits on the OGB but giving its members greater independence
> to act within those limits).
Keith, you have made that comment before and I still can't find any
basis for it in reality. The OGB has almost no powers. It has no
money.
It cannot hire or fire. It has no property. It cannot even make
copyright licensing decisions. In fact, the sole powers of the OGB
are to decide what content appears on opensolaris.org (which power
is entirely delegated to the communities) and the right to approve
or dismantle those communities. So, what powers are you talking about
and why are they unconscionable?
> The requirement for such widespread and
> intimate participation in government may well turn out to be a serious
> handicap in a community in which many or most participants would
> rather engineer software, especially if such an unbalanced situation
> arises. That's doubly true given that, so far, the balance of power
> is firmly against those who "just want to write code." If this
> situation persists, the OGB may need to consider structural changes to
> the Constitution, assuming it's ratified. What shape those changes
> might take would depend on the nature of the imbalance and the
> rulemaking areas into which the OGB chooses to wade.
Or the OGB can simply abolish the communities that abuse their right
to name core contributors, as is afforded by the constitution.
....Roy
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: Last Day for Nominations
Posted:
Mar 6, 2007 5:52 PM
in response to: fielding
|
|
On Tue, Mar 06, 2007 at 02:42:41PM -0800, Roy T. Fielding wrote:
> Keith, you have made that comment before and I still can't find any
> basis for it in reality. The OGB has almost no powers. It has no
> money.
> It cannot hire or fire. It has no property. It cannot even make
> copyright licensing decisions. In fact, the sole powers of the OGB
> are to decide what content appears on opensolaris.org (which power
> is entirely delegated to the communities) and the right to approve
> or dismantle those communities. So, what powers are you talking about
> and why are they unconscionable?
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 power, with or without the support of
the members, with or without review. This could, in a pessimistic
view, take the form of removing or weakening important quality
constraints, imposing useless process and inferior tools, or some
combination of both.
Let me distill it further: the OGB has the power to decide what code
may be integrated. In practice it will likely delegate that authority
to some subset of communities (via C-Teams) which will in turn impose
some generally consistent set of requirements (such as architectural
and code review). But nothing anywhere requires this; the
Constitution does not to enshrine any of that tradition in writing nor
provide any guidance to the OGB in recognising and codifying it.
> Or the OGB can simply abolish the communities that abuse their right
> to name core contributors, as is afforded by the constitution.
Certainly. And I expect the OGB will end up abolishing many
communities, though mainly for strategic rather than punitive reasons.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
142
From:
Newport Beach, California
Registered:
4/27/05
|
|
|
|
constitutional limitations
Posted:
Mar 7, 2007 1:55 PM
in response to: wesolows
|
|
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 power, with or without the support of
> the members, with or without review. This could, in a pessimistic
> view, take the form of removing or weakening important quality
> constraints, imposing useless process and inferior tools, or some
> combination of both.
Article VII delegates all such work to Community Groups. Article VIII
expressly limits the OGB's power to make any decisions for a community.
Article IX prevents the OGB from making changes to those limitations.
In other words, you must be thinking of a different constitution.
The OGB is first given all powers from the charter, and then forced to
delegate most of those powers, because that is how common governance
procedures prevent a situation wherein the delagatee gets hit by a bus,
requiring the powers to default somewhere that can delegate them again.
> Let me distill it further: the OGB has the power to decide what code
> may be integrated.
Nope. It has the power to stop integrations on opensolaris.org.
> In practice it will likely delegate that authority
> to some subset of communities (via C-Teams) which will in turn impose
> some generally consistent set of requirements (such as architectural
> and code review).
C-Teams are projects of a given community. What community that may
be will depend on the C and the restructuring of communities that
will have to be done by the next OGB to fit the ratified constitution.
If the OGB screws up, they can be replaced at any time.
> But nothing anywhere requires this; the
> Constitution does not to enshrine any of that tradition in writing nor
> provide any guidance to the OGB in recognising and codifying it.
Nor does it need to -- those are not governance issues, they are
decisions made by a community. The decisions will be made according
to the governance procedure in the constitution, but that is
significantly
different from enshrining one person (or one employer's) traditions
within the decision-making procedure itself. The personal and cultural
traditions and biases of the voting core contributors will determine
the results of each community decision, not some stale piece of
parchment.
They will hold to a given set of traditions for as long as the majority
of core contributors in that community hold to those traditions, and
quite a bit longer for code integration decisions (subject to veto).
The personal opinions of the responsible OGB members will determine
(with input from the community) how the actual work of OpenSolaris
is delegated to specific, self-governing community groups. The Members
as a whole are there to ensure that the OGB does such delegation
in a timely manner.
>> Or the OGB can simply abolish the communities that abuse their right
>> to name core contributors, as is afforded by the constitution.
>
> Certainly. And I expect the OGB will end up abolishing many
> communities, though mainly for strategic rather than punitive reasons.
The first task of the OGB (post-election) will have to be a reorg
of the existing communities into self-governing units. Everyone on
the current OGB realizes that. We postponed doing so until after
the election because we want the full constitution in place first,
with all of its checks and balances. Once the larger community
knows how to make its own decisions, it will have no problem giving
direction to the OGB for organizational adjustments.
....Roy
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: constitutional limitations
Posted:
Mar 7, 2007 3:02 PM
in response to: fielding
|
|
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 that the OGB delegate any particular
function to any or particular Community Groups. All Article VII does
is define how a Community Group forms or terminates and who composes
it. It does not require the existence or empowerment of any Community
Groups, much less that any or all of them are to have technical
control of existing consolidations. The OGB can act to make such
assignments, but nothing obligates it to do so. Indeed, if one
skipped article II, one would never even guess that the primary
function of this community is the maintenance and extension of an
existing operating system; none of the operative articles has anything
whatever to do with that purpose or mentions how the _already extant_
content of that operating system is to be managed. It's almost as if
the constitution were written with the intent that the OGB would
somehow form a collection of Community Groups which would sally forth
into the world creating project teams to go build an operating system
from scratch, along the way fabricating from whole cloth a novel
culture and set of social conventions.
> In other words, you must be thinking of a different constitution.
One can but hope. I'm referring to the one found at
http://www.opensolaris.org/os/community/cab/governance/.
> The OGB is first given all powers from the charter, and then forced to
> delegate most of those powers, because that is how common governance
Nothing in the Constitution requires the OGB to delegate anything.
7.1 merely permits their existence at the OGB's discretion.
> >Let me distill it further: the OGB has the power to decide what code
> >may be integrated.
>
> Nope. It has the power to stop integrations on opensolaris.org.
If one assumes the desirability of a unified engineering community,
these two are one and the same. Although I would phrase it slightly
differently to remove the dependency on a particular web site: the OGB
has the power to decide what code may be integrated into the
community's repositories. This allows for the possibility that Sun
will abandon its purported interest in open development, leaving the
OGB no less empowered to make decisions for the entire community - one
that no longer includes Sun employees - but stripped of Sun-supplied
infrastructure.
Don't get me wrong; this power must exist somewhere within the
OpenSolaris community. But its assignment to the OGB without
requiring subsequent delegation to (or even the existence of)
appropriate technical bodies is a major weakness in this proposed
constitution. Again, the code that requires open management _already_
_exists_ and is effectively controlled by Sun today, mainly because no
functional structure exists in which any other organisation can
exercise that control. The constitution as proposed offers absolutely
no improvement on this state of affairs; it leaves all powers in the
hands of the OGB. This is the same argument I've made since the
current basic structure was proposed, and no one has yet succeeded in
explaining why this concern is irrelevant or inappropriate, despite
the GWG's decision not to act on it.
> C-Teams are projects of a given community. What community that may
Yes, they should be. Could you please tell me which section in the
constitution requires this (or that technical control of the codebase
must be assigned in any fashion to one or more Community Groups, or
for that matter even acknowledges the necessity of exercising said
control)?
> Nor does it need to -- those are not governance issues, they are
> decisions made by a community. The decisions will be made according
> to the governance procedure in the constitution, but that is
> significantly
> different from enshrining one person (or one employer's) traditions
> within the decision-making procedure itself. The personal and cultural
> traditions and biases of the voting core contributors will determine
> the results of each community decision, not some stale piece of
> parchment.
Then perhaps you and I may be in agreement as to the effects of the
constitution (modulo your assertion that the OGB is required to
delegate any of its powers), and we disagree only as to the
desirability of these effects.
The Constitution as proposed does nothing to allocate, share, or limit
powers and responsibilities that the Charter does not already do. And
under that Charter, Community Groups have thus far exercised no power,
made no important decisions, and controlled (with any semblance of
transparency) no aspect of the process of engineering anything. As a
referendum on this state of affairs, the constitution fails
completely. As a guide to the next OGB's actions it offers little.
As an opportunity to confirm the OpenSolaris community's replacement
of Sun as the sole technical authority over OpenSolaris's engineering
practices and content, it is a lost one.
Unfortunately, the ratification vote is a catch-22: for whatever
reason, Sun (in the person of Stephen Harpster) has seen fit to extend
the original CAB members' terms of office not once but twice in an
effort to complete this work. If the constitution is not ratified,
the existing members will be expected to revise it until the community
approves or their term expires and Sun appoints someone else to
continue doing the same. But what hope do we have that the same
people will manage to fix in less than 4 months a problem the
existence or importance of which they spent a year consciously
denying? Sadly, it appears at this time that the best option is to
ratify the constitution, deficiencies and all, and hope that the next
OGB will make its clarification a top priority. Small wonder there's
been a surge in interest in governance - many may finally feel hope
that their concerns will be heard.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
142
From:
Newport Beach, California
Registered:
4/27/05
|
|
|
|
Re: constitutional limitations
Posted:
Mar 7, 2007 6:00 PM
in response to: wesolows
|
|
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 that the OGB delegate any particular
> function to any or particular Community Groups.
7.1: "... the OpenSolaris Community is held to be composed of
Community Groups that are initiated by the OGB for the purpose
of focused management and accomplishment of a given set of
activities. Community Groups are, in turn, responsible for
initiating and managing projects to accomplish those activities."
There is nothing in the OpenSolaris Community other than the set
of Communities initiated by the OGB, and the activities/products
governed by those Communities. By definition.
The charter says: "establish an OpenSolaris Governing Board (OGB)
to manage and direct an OpenSolaris community in its efforts to
improve upon and advocate in favor of OpenSolaris, so that the
community may long endure." That clearly says to me that the OGB
does not fulfill the charter if it does not initiate Community
Groups, since the constitution says there is no OpenSolaris
Community without said Groups.
Theoretically, the OGB could eliminate all activities by eliminating
all Community Groups, but the OGB itself serves entirely at the
discretion of the Core Contributors, who are in turn appointed
by the Community Groups as Members and said appointment survives
even if the OGB terminates their respective Community Group(s).
In short, even if the next OGB has its minds eaten by aliens and
forced by zombie-control to eliminate all the Community Groups
in one fell swoop, the same core contributors that elected that OGB
can fire them following the process defined in the constitution.
Your concerns have been heard several times. I find them to be
completely irrelevant to the proper operation of a governance model
that has a well-defined feedback mechanism. We don't need to write
down every possible screw-case that might apply because the system
is governed by people, not machines. We don't need to enshrine one
committee's view of how C-Teams operate in an organization-wide
constitution because C-Teams simply aren't relevant to *every*
activity at OpenSolaris, and the vast majority of comments we have
received so far clearly indicate that the existing consolidation
boundaries are arbitrary AND dysfunctional. Personally, I am hoping
that the communities feel empowered to change the things that are
obviously causing them harm right now, and let the consensus
process ensure that the traditions are adequately promoted and
maintained over time.
> All Article VII does
> is define how a Community Group forms or terminates and who composes
> it. It does not require the existence or empowerment of any Community
> Groups, much less that any or all of them are to have technical
> control of existing consolidations. The OGB can act to make such
> assignments, but nothing obligates it to do so. Indeed, if one
> skipped article II, one would never even guess that the primary
> function of this community is the maintenance and extension of an
> existing operating system; none of the operative articles has anything
> whatever to do with that purpose or mentions how the _already extant_
> content of that operating system is to be managed. It's almost as if
> the constitution were written with the intent that the OGB would
> somehow form a collection of Community Groups which would sally forth
> into the world creating project teams to go build an operating system
> from scratch, along the way fabricating from whole cloth a novel
> culture and set of social conventions.
Except for the minor detail that the initial Core Contributor set
is supposed to be representative of the existing (Open)Solaris
contributors, and hence the entire organization is subject to the
current set of people, culture, and traditions of the existing
operating system for the next two years (at least). That is,
assuming the community leaders did an adequate job of identifying
the core contributors of their own communities, at least to the
minimum extent necessary to ensure oversight of the OGB.
>> The OGB is first given all powers from the charter, and then
>> forced to
>> delegate most of those powers, because that is how common governance
>
> Nothing in the Constitution requires the OGB to delegate anything.
> 7.1 merely permits their existence at the OGB's discretion.
Read it carefully.
>>> Let me distill it further: the OGB has the power to decide what code
>>> may be integrated.
>>
>> Nope. It has the power to stop integrations on opensolaris.org.
>
> If one assumes the desirability of a unified engineering community,
> these two are one and the same. Although I would phrase it slightly
> differently to remove the dependency on a particular web site: the OGB
> has the power to decide what code may be integrated into the
> community's repositories. This allows for the possibility that Sun
> will abandon its purported interest in open development, leaving the
> OGB no less empowered to make decisions for the entire community - one
> that no longer includes Sun employees - but stripped of Sun-supplied
> infrastructure.
The OGB has the power to shut this organization down. Sun has the
power to shut down the OGB and remake this organization. BFD.
Having the power does not make it so.
> Don't get me wrong; this power must exist somewhere within the
> OpenSolaris community. But its assignment to the OGB without
> requiring subsequent delegation to (or even the existence of)
> appropriate technical bodies is a major weakness in this proposed
> constitution. Again, the code that requires open management _already_
> _exists_ and is effectively controlled by Sun today, mainly because no
> functional structure exists in which any other organisation can
> exercise that control. The constitution as proposed offers absolutely
> no improvement on this state of affairs; it leaves all powers in the
> hands of the OGB. This is the same argument I've made since the
> current basic structure was proposed, and no one has yet succeeded in
> explaining why this concern is irrelevant or inappropriate, despite
> the GWG's decision not to act on it.
We didn't "decide not to act on it". We decided that your comments
had no merit beyond the clarifications that were added to the
constitution where certain separations of responsibilities were
unclear. Further discussion of those concerns is irrelevant until
after the constitution that was approved by the OGB and Sun is
ratified by the community, after which there is a defined process
wherein you can propose an amendment for the Members to adopt.
>> C-Teams are projects of a given community. What community that may
>
> Yes, they should be. Could you please tell me which section in the
> constitution requires this (or that technical control of the codebase
> must be assigned in any fashion to one or more Community Groups, or
> for that matter even acknowledges the necessity of exercising said
> control)?
3.1, given the Charter's stated mission.
>> Nor does it need to -- those are not governance issues, they are
>> decisions made by a community. The decisions will be made according
>> to the governance procedure in the constitution, but that is
>> significantly
>> different from enshrining one person (or one employer's) traditions
>> within the decision-making procedure itself. The personal and
>> cultural
>> traditions and biases of the voting core contributors will determine
>> the results of each community decision, not some stale piece of
>> parchment.
>
> Then perhaps you and I may be in agreement as to the effects of the
> constitution (modulo your assertion that the OGB is required to
> delegate any of its powers), and we disagree only as to the
> desirability of these effects.
>
> The Constitution as proposed does nothing to allocate, share, or limit
> powers and responsibilities that the Charter does not already do. And
> under that Charter, Community Groups have thus far exercised no power,
> made no important decisions, and controlled (with any semblance of
> transparency) no aspect of the process of engineering anything. As a
> referendum on this state of affairs, the constitution fails
> completely. As a guide to the next OGB's actions it offers little.
> As an opportunity to confirm the OpenSolaris community's replacement
> of Sun as the sole technical authority over OpenSolaris's engineering
> practices and content, it is a lost one.
None of the current Communities on opensolaris.org are operating as
a Community Group, as defined by the governance. The constitution
hasn't even been enforced yet, even though the charter placed it into
effect as soon as it was approved by the OGB and Sun. Some of
the OGB members felt that it would be inappropriate to enforce the
constitution until after it is ratified by the community and a
fully elected OGB has been established.
All along this project, the CAB has been hamstrung by our unwillingness
to force EVERYONE concerned to obey a single set of open principles
while making decisions for the OpenSolaris project. It is easy to
create Communities and Projects in an ad hoc, undisciplined manner
with weak scope and unclear objectives -- it is much harder to remove
or reorganize them on an ad hoc basis, or to deal with internal
conflicts when the contributors aren't all working for the same boss.
The constitution won't really be tested until there is no other
behind-the-scenes alternative to making decisions, at which point
it will either succeed or fail based upon the community's willingness
to obey its own procedures.
There is nothing more we can ask for, and nothing more that we can do,
other than to ensure that the constitution can be changed later
if changes become necessary. I would hope, however, that folks here
have the sense to realize that they should focus on correcting the
misbehavior first and actually give on-list collaboration a try,
rather than assume a document that hasn't even been obeyed yet
has some fundamental flaws. The same structure is in use by several
successful open source projects, in addition to the 45+ distinct
communities at Apache, precisely because it provides an agreed upon
mechanism for resolving conflict in the face of competing demands
from many individuals who happen to work for many different companies.
....Roy
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
818
From:
San Francisco CA US
Registered:
3/9/05
|
|
|
|
Re: constitutional limitations
Posted:
Mar 7, 2007 7:03 PM
in response to: fielding
|
|
On Wed, Mar 07, 2007 at 06:00:11PM -0800, Roy T. Fielding wrote:
> activity at OpenSolaris, and the vast majority of comments we have
> received so far clearly indicate that the existing consolidation
> boundaries are arbitrary AND dysfunctional. Personally, I am hoping
I never suggested that consolidation boundaries should be encoded in
the constitution, only the notion that a non-empty set of Community
Groups exist to control portions of the codebase.
> The OGB has the power to shut this organization down. Sun has the
> power to shut down the OGB and remake this organization. BFD.
Sun does not.
# 11. This Charter may be amended if both the OGB and Sun
# agree.
Unless the OGB agrees, the basis for its powers cannot be revoked by
Sun. Even if it could, nothing would obligate the OGB to honour that
decision; the license to the code is irrevocable and while Sun's
decision to prohibit its employees from participating (that is,
essentially, to make a proprietary fork) would be a heavy blow, it
would not by itself preclude others from continuing to do useful work
under the OGB's leadership.
> We didn't "decide not to act on it". We decided that your comments
> had no merit beyond the clarifications that were added to the
> constitution where certain separations of responsibilities were
> unclear. Further discussion of those concerns is irrelevant until
And I've spent the last several hundred lines explaining that not only
is the division of responsibilities unclear, it's practically
nonexistent insofar as 'responsibilities' are held to include anything
even vaguely related to managing the millions of lines of existing
code.
> a Community Group, as defined by the governance. The constitution
> hasn't even been enforced yet, even though the charter placed it into
> effect as soon as it was approved by the OGB and Sun. Some of
> the OGB members felt that it would be inappropriate to enforce the
> constitution until after it is ratified by the community and a
> fully elected OGB has been established.
They should have felt that doing so would be inappropriate given that
it's prohibited by the Charter. Section 3 of the Charter states:
# The OGB shall define and implement a process for its
# ratification of the Constitution, in a manner consistent
# with democratic principles. This process shall at a minimum
# involve members of the OpenSolaris community in addition to
# the membership of the OGB.
The Constitution is not operable until ratification takes place under
that process.
Regardless, nothing in the constitution requires that the
responsibilities of a Community Group be any different from those of
today's largely useless and dysfunctional Communities. It only
requires that they adopt more rigorous processes for making their
still-undefined decisions. Helpful, perhaps, but hardly core.
> The constitution won't really be tested until there is no other
> behind-the-scenes alternative to making decisions, at which point
> it will either succeed or fail based upon the community's willingness
> to obey its own procedures.
Agreed. As far as I'm concerned, that state of affairs begins the
instant the constitution is ratified. Which is inconsistent, to say
the least, with a document that does nothing to require delegation of
the minimum authority required to allow work to continue. This will
undoubtedly lead to a long and messy transition period, during which
egos will be bruised, confusion will interfere with work, and
responsibilities will be unclear. And the abolition (or restriction
of scope) of Sun-internal bodies not sanctioned by the OGB and in
direct conflict with open development will be put off yet longer,
perhaps indefinitely. Hardly what I'd consider an ideal state.
> has some fundamental flaws. The same structure is in use by several
> successful open source projects, in addition to the 45+ distinct
> communities at Apache, precisely because it provides an agreed upon
> mechanism for resolving conflict in the face of competing demands
> from many individuals who happen to work for many different companies.
Clearly those using these structures successfully are not using them
alone, since they do not describe who is responsible for making any
decision that might reasonably lead to such a conflict. Except,
perhaps, a metaconflict such as this one.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Registered:
6/14/05
|
|
|
|
Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:29 AM
in response to: alanc
|
|
Alan Coopersmith wrote:
> For Xorg on sparc, I didn't list you because you have not yet
> contributed anything to the X Community - but I was also very
> unsure who to list when I generated the list of Core Contributors.
> I'm sure once we get going on integrating your work into the X
> Community, you'll count as a Core Contributor for X in the future,
> but my understanding was Contributor status was supposed to reflect
> past results, not future plans.
Okay, I indeed didn't publish any diffs (so far).
But at least the working b****ies (April 2006, as part of marTux_0.1),
for the first time ever a functional Xorg for sparc-Solaris ( see
http://www.opensolaris.org/os/community/x_win/announcements/#2006-04-10_announcing_martux_0_1_livecd_for_sparc
).
And I hence _showed_ that a once neglected (or probably forever
deferred) project could be turned into reality easily and quickly, with
not too much headaches.
The required patches were so **** small initially (Xorg 6.9.0), that I
didn't even dare to release them as actual "patches", because you might
have loughed.
My achievement may not be huge porting work in this case, but _that_ I
didn't give up in getting things built __plus__(!) properly working.
You now _know_, THAT IT IS POSSIBLE to easily bring Xorg to sparc (and
even sparcv9 kernels).
That's in my eyes not a vague future announcement thing, but a benefit
you already have.
The full diffs will be released until March31st, including afb and ffb
support (based on 7.2.0).
Martin
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Registered:
6/14/05
|
|
|
|
Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 10:50 AM
in response to: bochnig
|
|
Martin Bochnig wrote:
> Alan Coopersmith wrote:
>
>> For Xorg on sparc, I didn't list you because you have not yet
>> contributed anything to the X Community - but I was also very
>> unsure who to list when I generated the list of Core Contributors.
>> I'm sure once we get going on integrating your work into the X
>> Community, you'll count as a Core Contributor for X in the future,
>> but my understanding was Contributor status was supposed to reflect
>> past results, not future plans.
>
Situation BEFORE I released my binaries:
http://blogs.sun.com/alanc/entry/xorg_for_solaris_sparc
Thursday February 16, 2006
Xorg for Solaris SPARC?
I got two comments quickly after my last post, and have been asked a few
other times lately, so I'll post the answer here as a new entry so it's
more visible. The question is “/So when will we have Xorg on Solaris
SPARC?/” The answer unfortunately is simply “/I don't know/.” The Sun
Ray team <http:// are working on porting the Sun
Ray drivers to Xorg and the SPARC graphics group are porting the
XVR-2500
<http://
drivers to Xorg. Our group provides assistance as needed, but most of
the work is in the hands of those groups, and I don't know their plans
for release schedules yet (and it wouldn't be my place to announce for
them even if I did). It's being worked on, but that's about all I know
or can say right now.
[Technorati Tags: Xorg <http://, X11
<http://, Solaris
<http://, OpenSolaris
<http://]
Posted at 09:29AM Feb 16, 2006
<http:// by Alan
Coopersmith in Solaris | Comments[5]
<http://
_________________________________________________________________
=====================================
----------------------------------------------------------------------------- ---------
Situation AFTER my various postings to
http://opensolaris.org/os/community/x_win/discussions/ :
You released Xorg for SPARC by yourself (limited to the wsfb driver) :
http://opensolaris.org/os/community/x_win/announcements/
Martin Bochnig
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
5,829
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Last Day for Nominations
Posted:
Mar 6, 2007 11:09 PM
in response to: bochnig
|
|
Martin Bochnig wrote:
> Situation BEFORE I released my binaries:
> http://blogs.sun.com/alanc/entry/xorg_for_solaris_sparc
> Situation AFTER my various postings to
> http://opensolaris.org/os/community/x_win/discussions/ :
> You released Xorg for SPARC by yourself (limited to the wsfb driver) :
> http://opensolaris.org/os/community/x_win/announcements/
While your work is appreciated, and may someday form our solution for
older devices, it didn't really have a bearing there.
We've been building Xorg on Solaris SPARC since we first created the
Xorg 6.8 tree for Solaris 10 - we just never released the packages
because there were no drivers.
The delivery now was due to two reasons:
1) The manager of the SPARC graphics group asked me to, since they
were getting near the point they'd be ready to test their
XVR-2500 driver and didn't want to have to worry about coordination
issues in whatever build they're ready to deliver. (I still can't
tell you when that will be - I've seen it running on a test system
in one of their engineer's offices, but it definitely needs more
work still).
2) When looking at some of the putbacks to the X.Org community by the
maintainers of the wsfb driver for BSD I noticed the interface
looked very similar to the Solaris /dev/fb interface, and a couple
of months later, finally got a chance to try porting it. It worked
well enough to serve as a test case so we could at least test Xorg
on SPARC with some sort of real hardware so we wouldn't be delivering
untested code to Solaris.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Registered:
6/14/05
|
|
|
|
Re: Re: Last Day for Nominations
Posted:
Mar 7, 2007 3:46 AM
in response to: alanc
|
|
Alan Coopersmith wrote:
> Martin Bochnig wrote:
>
>> Situation BEFORE I released my binaries:
>> http://blogs.sun.com/alanc/entry/xorg_for_solaris_sparc
>> Situation AFTER my various postings to
>> http://opensolaris.org/os/community/x_win/discussions/ :
>> You released Xorg for SPARC by yourself (limited to the wsfb driver) :
>> http://opensolaris.org/os/community/x_win/announcements/
>
>
> While your work is appreciated, and may someday form our solution for
> older devices, it didn't really have a bearing there.
>
> We've been building Xorg on Solaris SPARC since we first created the
> Xorg 6.8 tree for Solaris 10 - we just never released the packages
> because there were no drivers.
Aha, you never told.
Didn't you always say (i.e. in IRC), the server binary would not compile
on/for sparc?
Okay, maybe you just couldn't disclose too many of the internal goings.
Okay.
>
> The delivery now was due to two reasons:
>
> 1) The manager of the SPARC graphics group asked me to, since they
> were getting near the point they'd be ready to test their
> XVR-2500 driver and didn't want to have to worry about coordination
> issues in whatever build they're ready to deliver. (I still can't
> tell you when that will be - I've seen it running on a test system
> in one of their engineer's offices, but it definitely needs more
> work still).
>
> 2) When looking at some of the putbacks to the X.Org community by the
> maintainers of the wsfb driver for BSD I noticed the interface
> looked very similar to the Solaris /dev/fb interface, and a couple
> of months later, finally got a chance to try porting it. It worked
> well enough to serve as a test case so we could at least test Xorg
> on SPARC with some sort of real hardware so we wouldn't be delivering
> untested code to Solaris.
>
Okay.
You get it as soon as I have ported the patch to 7.2 .
(DEADLINE: March31st, I need PRESSURE and specific dates, therefore)
Thanks and regards,
Martin
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Registered:
6/14/05
|
|
|
|
Re: Re: Last Day for Nominations
Posted:
Mar 5, 2007 11:30 AM
in response to: alanc
|
|
Alan Coopersmith wrote:
> For Xorg on sparc, I didn't list you because you have not yet
> contributed anything to the X Community
Sounds disappointing.
And I did not provide binaries alone (Xorg for sparc including PGX,
PGX24, PGX32, PGX64 and XVR-100 drivers), but also source: The
Aperture-amd64 patch (with that tricky -mcmodel=kernel).
http://www.opensolaris.org/jive/thread.jspa?threadID=10420&tstart=75
http://www.opensolaris.org/jive/thread.jspa?threadID=10593&tstart=75
Now in Xorg's (and XFree86's) main branch, placed there by y. :
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=6bd4c254396cb0f4e8ae21ff455ebb15cd9f4f10
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=6bd4c254396cb0f4e8ae21ff455ebb15cd9f4f10
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/etc/apSolaris.shar
> - but I was also very
> unsure who to list when I generated the list of Core Contributors.
> I'm sure once we get going on integrating your work into the X
> Community, you'll count as a Core Contributor for X in the future,
> but my understanding was Contributor status was supposed to reflect
> past results, not future plans.
>
> For your work on martux though, I think you would easily qualify for
> one of the "Contributor at Large" spots, by mailing cab-discuss to
> request such status.
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
