From Jim.Grisanzio at Sun.COM Wed Oct 5 12:22:42 2005 From: Jim.Grisanzio at Sun.COM (Jim Grisanzio) Date: Wed, 05 Oct 2005 12:22:42 -0700 Subject: [cab-discuss] CAB Meeting Notes: Sept 28 2005 Message-ID: <43442802.4020101@sun.com> Below are notes from the CAB meeting last Wednesday. My notes from this meeting are a bit thin, and for that I apologize, but I'm running a bit behind right now. I did want to document what occurred in a general sense, though. Jim -- Jim Grisanzio, Community Manager, OpenSolaris http://blogs.sun.com/jimgris/ CAB Meeting Notes: Sept 28, 2005 All CAB members present Jim Grisanzio Stephen Hahn The entire meeting consisted of the CAB and Stephen Hahn discussing Stephen's feedback (http://www.opensolaris.org/jive/thread.jspa?threadID=2561&tstart=0) on the latest version of the CAB's charter (http://www.opensolaris.org/jive/thread.jspa?threadID=2156&tstart=0). The current draft of the Charter was written by Al Hopper based on multiple CAB conversations and community feedback. At this point, the CAB would like Jim G. to incorporate edits for Al, the other CAB members, community members, and Sun as the Charter comes to fruition and is approved. This is to simply free some time for the CAB, so they can comment and decide issues more rapidly without also having to edit and track changes in documents. If this works out to everyone's satisfaction, Jim G. will provide the same service for the Governance, which was written by Roy based on CAB meetings just as the Charter. Special thanks to Al and Roy for that work. Specific American government and judicial references in the Charter will be removed since the document needs to be understood globally. But we will keep the generic terms "Declaration of Independence" for the Charter to document the CAB's scope and "Constitution" for the Governance to document the actual functioning rules for the community. We will not use those terms as titles of the documents, per say, but just to easily explain the difference. The history section of the Charter and some of the context will be removed and placed in a cover letter to Sun. That was the CAB's original intent. This content is important commentary, but some have commented that sometimes hinders the understanding of the CAB's intent for the Charter itself. The final Charter document will be shorter as a result. Jim will post the next rev of the Charter on Friday Oct 7 that addresses S. Hahn's feedback. Current Charter Draft and Ratification Schedule * Fri Oct 7: Updated draft Charter posted to CAB list * Wed Oct 12: CAB conference call to discuss latest draft * Wed Oct 19: CAB/Hahn conference call to finalize any last issues. * Fri Oct 21: Charter submitted to Sun for approval * Wed Oct 26: Possible CAB call to address any issues with submission * Wed Nov 2: Possible CAB call to address any issues with submission * w/o Nov 14: Possible Charter approved if no issues are flagged Approval process at Sun: When the CAB and S. Hahn agree on the Charter language, Stephen will engage Sun management for the final approvals. We are all shooting for a mid November approval but we have some flexibility in the road map schedule. From Jim.Grisanzio at Sun.COM Fri Oct 7 18:20:55 2005 From: Jim.Grisanzio at Sun.COM (Jim Grisanzio) Date: Fri, 07 Oct 2005 18:20:55 -0700 Subject: [cab-discuss] OpenSolaris Charter: draft v2 Message-ID: <43471EF7.9000505@sun.com> CAB, At the CAB's request, I have updated the OpenSolaris Charter. Some elements of this document point to the OpenSolaris Governance (which is also in draft form), so the two documents need to be considered together. I've done my best to evaluate all edits and opinions. The document as currently still open for review. Jim --- Jim Grisanzio, Community Manager, OpenSolaris http://blogs.sun.com/jimgris/ The OpenSolaris Charter (10/07/05 draft) Introduction The OpenSolaris Charter is the title and deed that Sun Microsystems has transferred to the OpenSolaris community. The OpenSolaris Governing Board (OGB) is the body that now holds this authority, represents the community, and acts on the community's behalf. Brief History of the OpenSolaris Project In early 2004, Sun initiated the project to open source the Solaris operating system. A multi-disciplinary team was formed to consider all the aspects of the project: licensing, business model, governance, co-development, source code analysis, source code management, tools, marketing, and community development. A pilot program was formed in September of 2004 with 18 non-Sun community members and ran for 9 months growing to 145 external participants. On January 25, 2005, Sun (1) opened the initial opensolaris.org web site, (2) announced that OpenSolaris would be released under the CDDL (Common Development and Distribution License), (3) released DTrace under that license, and (4) announced the intention to form a Community Advisory Board (CAB) of five members -- two Sun employees, two OpenSolaris Pilot Program participants elected by the community, and one open source community member. The five CAB members were introduced publicly on April 4, 2005, and OpenSolaris was officially launched on June 14, 2005. When the CAB was formed, Sun requested that the group write two critical documents: (1) a Charter detailing a governing board's scope and (2) a Governance outlining how the OpenSolaris community would function. Sun's intention was to not only open the Solaris source code, but to also transfer the operations, stewardship, and management of the project to the OpenSolaris community -- which is now represented by the OGB. OGB Mission Statement The OGB provides formal representation and structure for the OpenSolaris community via the OpenSolaris Charter and the OpenSolaris Governance. OGB Scope The scope of the OGB covers anything related to the OpenSolaris project. In this context, scope means that the OGB has the authority to get involved in all aspects of the project to ensure that the community is properly represented. Management of the OpenSolaris project -- including the source code and its evolution -- is now under the control of the OpenSolaris community. That community includes the OpenSolaris developers, system administrators, users, evangelists, and marketers involved with the project, and their roles are outlined by the OpenSolaris Governance. The OGB gets involved when there are disputes or when there are new issues to be devised. OpenSolaris Governing Board Elections The OGB consists of seven members who are elected by OpenSolaris community members with voting privileges as defined in the OpenSolaris Governance. A quorum of five OGB members will be required to make significant changes to any of the OpenSolaris governing documents and those documents will have to be ratified by the community. OGB candidates are OpenSolaris members in good standing, nominated by the OpenSolaris membership, and must accept the nomination to be considered. The voting process is the Single Transferable Vote (STV). Elections are held once a year on the anniversary of the formation of the first OGB. There are no term limits. Board members will not be assigned specific functions. If a board member resigns or is otherwise unable to complete his or her term, the next runner-up in the election will fill that position. There is no termination from the Board other than by resignation within a term. The board may, at its discretion and with a quorum of 5 OGB members, decide to dissolve itself to force a new election. Single Transferable Vote OGB members are elected by "Single Transferable Vote" as described at: http://www.electoral-reform.org.uk/votingsystems/stvi.htm http://www.cix.co.uk/~rosenstiel/stvrules/index.htm http://stv.sourceforge.net/ To summarize, each member has one vote, but it is cast as an ordered list of preferred candidates. A later preference is considered only if an earlier preference has a surplus above the quota required for election or is excluded because of insufficient support. Under no circumstances will a later preference count against an earlier preference. The effect of STV is to balance representation across all significant groups in the community. Legal Status The OGB operates within the scope of this Charter and is not an independent legal entity. Sun is the lead copyright holder of the OpenSolaris code, and any legal disputes are resolved by Sun. Community Costs At this time, Sun has agreed to fund the OpenSolaris project, which includes all the infrastructure, the website, the source code management system and related build and package management tools, marketing and community development functions, and the administrative costs of the OGB (including travel expenses for up to two OGB meetings a year). - End - From fielding at gbiv.com Tue Oct 11 14:36:45 2005 From: fielding at gbiv.com (Roy T. Fielding) Date: Tue, 11 Oct 2005 14:36:45 -0700 Subject: [cab-discuss] SCM and its effect on governance Message-ID: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> > Subversion isn't a distributed SCM, so it's not a contender for that > portion. (The simplest way to identify a distributed SCM is that one > repository can pull from or push to any other as a natural operation.) I think we have been given this as a requirement from Sun engineering without any consideration for its effect on governance. The model of development using a distributed SCM is for each individual or team to maintain its own branches and occasionally submit complete change sets to a higher-level individual managing a gateway for release. In general, there is no independent review of such changes until a merge/put-over is requested, at which time the benevolent dictator/gateway for the destination branch determines, possibly after consulting with others, whether or not the merge takes place. That model fits the development process at Sun today because there is a known hierarchy of Sun employees whose role is to act as a gateway manager according to the procedures set out by Sun. Coincidentally (or not), it is also the model that Linux uses for inclusion of code in the kernel, and what most of the Linux distros use for the rest of their operating systems as well (i.e., package maintainers as gateways). It is important to note, however, that this is not collaborative development in the Apache sense of development. It is open source by virtue of the resulting products, but not collaborative because there is no notion of peers in the decision-making process. It is truly hierarchical in both authority and life cycle -- each individual gateway controls its own destiny until the maintainer fails, at which point a new maintainer is assigned or the software replaced by an entirely separate line of development with its own maintainer. In fact, even with an active maintainer, the normal result of a change request is that the benevolent dictator takes the patch and changes it arbitrarily to fit what they personally feel is worth committing to their own code base. Hierarchy has the advantage of there not being a need to vote on decisions, but has the disadvantages of there being almost no peer review of independently delivered parts until very late in the development process (typically, long after the original developer has any interest in making changes to correspond to reviewer input) and an extreme vulnerability to benevolent dictator overload. This is in contrast to the collaborative model used by FreeBSD, Apache, PHP, etc., wherein almost all development takes place on branches within a single centralized repository viewable by everyone interested in the project and changes are reviewed as soon as they are made. This model removes barriers to entry from the community, allowing them to participate in development during the stages when their participation has the greatest impact (i.e., design and early prototyping). It also gives the public an easy way to start contributing, simply by reviewing commit messages as they occur and pointing out mistakes when they are inserted in the code. When I got involved in OpenSolaris, folks assured me that Sun wanted to see a governance model that reflected the collaborative method of open source, not the benevolent dictatorship of Linux. However, every time we talk to Sun engineering it seems clear that they assume their current model of development cannot be changed and thus nothing other than distributed SCM is possible. Such a model assumes that key Sun engineers will be the gateways and Sun ARCs will define the minimal criteria for gateway acceptance. I think hell will freeze over before Sun will allow any outsiders to be a benevolent dictator for any portion of OpenSolaris considered essential to Solaris. The collaborative model is safe for Sun because it has the effect of protecting everyone's most important interests (veto power on changes based on technical rationale) while treating everyone as peers. In contrast, the hierarchical model places an individual in that position and everyone must trust that individual to be even-handed. Nevertheless, it is still a valid model for OpenSolaris, since there is no effective difference between having a closed group at Sun determine who the dictators shall be versus the Linux method of having Linus Torvalds do the same. I should note, however, that Linux would have failed miserably if Linus were not such a nice guy that is respected by the entire community. So, I have to ask again: what is it that Sun wants in a governance model for OpenSolaris? Do you want a collaborative model in which outsiders are peers in the development process, or do you want a hierarchical model in which outsiders merely contribute and hope to obtain benefits from the process? Do you want this project to be more like Linux or more like FreeBSD? I can write a governance process that works one way or the other, but I will not write one that attempts to do both. Dictators and collaborative development do not mix. ....Roy From Glynn.Foster at Sun.COM Tue Oct 11 15:45:28 2005 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Wed, 12 Oct 2005 11:45:28 +1300 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> Message-ID: <1129070728.7865.496.camel@slipstream> Hey, On Tue, 2005-10-11 at 14:36 -0700, Roy T. Fielding wrote: > > Subversion isn't a distributed SCM, so it's not a contender for that > > portion. (The simplest way to identify a distributed SCM is that one > > repository can pull from or push to any other as a natural operation.) > > I think we have been given this as a requirement from Sun engineering > without any consideration for its effect on governance. Not to be too negative, but have we? I've seen zero requirements being published out on the public lists, which I find personally quite disappointing on such a wide reaching decision. Glynn From webmink at sun.com Tue Oct 11 16:08:41 2005 From: webmink at sun.com (Simon Phipps) Date: Wed, 12 Oct 2005 00:08:41 +0100 Subject: [cab-discuss] OpenSolaris Charter: draft v2 In-Reply-To: <43471EF7.9000505@sun.com> References: <43471EF7.9000505@sun.com> Message-ID: This looks great, Jim - all the same points, more focus and ./much/ shorter. I'd like to run through this and if we all agree make it our release candidate at tomorrow's meeting. Thanks Simon _____ Simon Phipps, Chief Open Source Officer, Sun Microsystems Tel: +1 650 352 6327/USx69758 Web: www.webmink.net, AIM: webmink Current timezone: BST (UTC+1) On Oct 8, 2005, at 02:20, Jim Grisanzio wrote: > CAB, > > At the CAB's request, I have updated the OpenSolaris Charter. Some > elements of this document point to the OpenSolaris Governance > (which is also in draft form), so the two documents need to be > considered together. I've done my best to evaluate all edits and > opinions. The document as currently still open for review. > > Jim > --- > Jim Grisanzio, Community Manager, OpenSolaris > http://blogs.sun.com/jimgris/ > > > > > The OpenSolaris Charter > (10/07/05 draft) > > > Introduction > > The OpenSolaris Charter is the title and deed that Sun Microsystems > has transferred to the OpenSolaris community. The OpenSolaris > Governing Board (OGB) is the body that now holds this authority, > represents the community, and acts on the community's behalf. > > > Brief History of the OpenSolaris Project > > In early 2004, Sun initiated the project to open source the Solaris > operating system. A multi-disciplinary team was formed to consider > all the aspects of the project: licensing, business model, > governance, co-development, source code analysis, source code > management, tools, marketing, and community development. A pilot > program was formed in September of 2004 with 18 non-Sun community > members and ran for 9 months growing to 145 external participants. > > On January 25, 2005, Sun (1) opened the initial opensolaris.org web > site, (2) announced that OpenSolaris would be released under the > CDDL (Common Development and Distribution License), (3) released > DTrace under that license, and (4) announced the intention to form > a Community Advisory Board (CAB) of five members -- two Sun > employees, two OpenSolaris Pilot Program participants elected by > the community, and one open source community member. The five CAB > members were introduced publicly on April 4, 2005, and OpenSolaris > was officially launched on June 14, 2005. > > When the CAB was formed, Sun requested that the group write two > critical documents: (1) a Charter detailing a governing board's > scope and (2) a Governance outlining how the OpenSolaris community > would function. Sun's intention was to not only open the Solaris > source code, but to also transfer the operations, stewardship, and > management of the project to the OpenSolaris community -- which is > now represented by the OGB. > > > OGB Mission Statement > > The OGB provides formal representation and structure for the > OpenSolaris community via the OpenSolaris Charter and the > OpenSolaris Governance. > > > OGB Scope > > The scope of the OGB covers anything related to the OpenSolaris > project. In this context, scope means that the OGB has the > authority to get involved in all aspects of the project to ensure > that the community is properly represented. Management of the > OpenSolaris project -- including the source code and its evolution > -- is now under the control of the OpenSolaris community. That > community includes the OpenSolaris developers, system > administrators, users, evangelists, and marketers involved with the > project, and their roles are outlined by the OpenSolaris > Governance. The OGB gets involved when there are disputes or when > there are new issues to be devised. > > > OpenSolaris Governing Board Elections > > The OGB consists of seven members who are elected by OpenSolaris > community members with voting privileges as defined in the > OpenSolaris Governance. A quorum of five OGB members will be > required to make significant changes to any of the OpenSolaris > governing documents and those documents will have to be ratified by > the community. OGB candidates are OpenSolaris members in good > standing, nominated by the OpenSolaris membership, and must accept > the nomination to be considered. The voting process is the Single > Transferable Vote (STV). Elections are held once a year on the > anniversary of the formation of the first OGB. There are no term > limits. > > Board members will not be assigned specific functions. If a board > member resigns or is otherwise unable to complete his or her term, > the next runner-up in the election will fill that position. There > is no termination from the Board other than by resignation within a > term. The board may, at its discretion and with a quorum of 5 OGB > members, decide to dissolve itself to force a new election. > > > Single Transferable Vote > > OGB members are elected by "Single Transferable Vote" as described at: > > http://www.electoral-reform.org.uk/votingsystems/stvi.htm > http://www.cix.co.uk/~rosenstiel/stvrules/index.htm > http://stv.sourceforge.net/ > > To summarize, each member has one vote, but it is cast as an > ordered list of preferred candidates. A later preference is > considered only if an earlier preference has a surplus above the > quota required for election or is excluded because of insufficient > support. Under no circumstances will a later preference count > against an earlier preference. The effect of STV is to balance > representation across all significant groups in the community. > > > Legal Status > > The OGB operates within the scope of this Charter and is not an > independent legal entity. Sun is the lead copyright holder of the > OpenSolaris code, and any legal disputes are resolved by Sun. > > > Community Costs > > At this time, Sun has agreed to fund the OpenSolaris project, which > includes all the infrastructure, the website, the source code > management system and related build and package management tools, > marketing and community development functions, and the > administrative costs of the OGB (including travel expenses for up > to two OGB meetings a year). > > > - End - > > _______________________________________________ > cab-discuss mailing list > cab-discuss at opensolaris.org > From benr at cuddletech.com Wed Oct 12 03:06:15 2005 From: benr at cuddletech.com (Ben Rockwood) Date: Wed, 12 Oct 2005 03:06:15 -0700 Subject: [cab-discuss] OpenSolaris Charter: draft v2 In-Reply-To: References: <43471EF7.9000505@sun.com> Message-ID: <434CE017.7040706@cuddletech.com> Simon Phipps wrote: > This looks great, Jim - all the same points, more focus and ./much/ > shorter. I'd like to run through this and if we all agree make it our > release candidate at tomorrow's meeting. Indeed, good job Jim. Pushing out a release candidate would be great. I still have problems with the charter (all mentioned in the past, still unresolved in my mind) but I think an RC will give us something to really start chewing on and getting people interested since we're moving toward a result. I'm looking forward to getting a much larger audience involved around the charter. Full speed ahead! benr. From al at logical-approach.com Wed Oct 12 07:16:03 2005 From: al at logical-approach.com (Al Hopper) Date: Wed, 12 Oct 2005 09:16:03 -0500 (CDT) Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: <1129070728.7865.496.camel@slipstream> References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> <1129070728.7865.496.camel@slipstream> Message-ID: On Wed, 12 Oct 2005, Glynn Foster wrote: > Hey, > > On Tue, 2005-10-11 at 14:36 -0700, Roy T. Fielding wrote: > > > Subversion isn't a distributed SCM, so it's not a contender for that > > > portion. (The simplest way to identify a distributed SCM is that one > > > repository can pull from or push to any other as a natural operation.) > > > > I think we have been given this as a requirement from Sun engineering > > without any consideration for its effect on governance. > > Not to be too negative, but have we? I've seen zero requirements being > published out on the public lists, which I find personally quite > disappointing on such a wide reaching decision. Agreed. The analysis that was done was not shared with the community or done with community input or participation. The result of the analysis, which took several weeks, was shared in a 5 line (or so) paragraph. In fact, I don't even know who worked on the analysis! I'll persue this up as a CAB action item. We can, and must, do better than this type of "black op" behavior if the OpenSolaris project is to be successful. Regards, Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 From al at logical-approach.com Wed Oct 12 07:18:31 2005 From: al at logical-approach.com (Al Hopper) Date: Wed, 12 Oct 2005 09:18:31 -0500 (CDT) Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> Message-ID: On Tue, 11 Oct 2005, Roy T. Fielding wrote: > > Subversion isn't a distributed SCM, so it's not a contender for that > > portion. (The simplest way to identify a distributed SCM is that one > > repository can pull from or push to any other as a natural operation.) > > I think we have been given this as a requirement from Sun engineering > without any consideration for its effect on governance. > > The model of development using a distributed SCM is for each > individual or team to maintain its own branches and occasionally > submit complete change sets to a higher-level individual managing > a gateway for release. In general, there is no independent review > of such changes until a merge/put-over is requested, at which time > the benevolent dictator/gateway for the destination branch > determines, possibly after consulting with others, whether or not > the merge takes place. > > That model fits the development process at Sun today because > there is a known hierarchy of Sun employees whose role is to act > as a gateway manager according to the procedures set out by Sun. > > Coincidentally (or not), it is also the model that Linux uses > for inclusion of code in the kernel, and what most of the Linux > distros use for the rest of their operating systems as well > (i.e., package maintainers as gateways). > > It is important to note, however, that this is not collaborative > development in the Apache sense of development. It is open source > by virtue of the resulting products, but not collaborative because > there is no notion of peers in the decision-making process. It is > truly hierarchical in both authority and life cycle -- each > individual gateway controls its own destiny until the maintainer > fails, at which point a new maintainer is assigned or the software > replaced by an entirely separate line of development with its > own maintainer. In fact, even with an active maintainer, the > normal result of a change request is that the benevolent dictator > takes the patch and changes it arbitrarily to fit what they > personally feel is worth committing to their own code base. > > Hierarchy has the advantage of there not being a need to vote on > decisions, but has the disadvantages of there being almost no peer > review of independently delivered parts until very late in the > development process (typically, long after the original developer > has any interest in making changes to correspond to reviewer input) > and an extreme vulnerability to benevolent dictator overload. > > This is in contrast to the collaborative model used by FreeBSD, > Apache, PHP, etc., wherein almost all development takes place > on branches within a single centralized repository viewable > by everyone interested in the project and changes are reviewed > as soon as they are made. This model removes barriers to entry > from the community, allowing them to participate in development > during the stages when their participation has the greatest > impact (i.e., design and early prototyping). It also gives the > public an easy way to start contributing, simply by reviewing > commit messages as they occur and pointing out mistakes when > they are inserted in the code. > > When I got involved in OpenSolaris, folks assured me that Sun > wanted to see a governance model that reflected the collaborative > method of open source, not the benevolent dictatorship of Linux. > However, every time we talk to Sun engineering it seems clear that > they assume their current model of development cannot be changed > and thus nothing other than distributed SCM is possible. Such a > model assumes that key Sun engineers will be the gateways and > Sun ARCs will define the minimal criteria for gateway acceptance. > > I think hell will freeze over before Sun will allow any outsiders > to be a benevolent dictator for any portion of OpenSolaris > considered essential to Solaris. The collaborative model is safe > for Sun because it has the effect of protecting everyone's most > important interests (veto power on changes based on technical > rationale) while treating everyone as peers. In contrast, the > hierarchical model places an individual in that position and > everyone must trust that individual to be even-handed. > Nevertheless, it is still a valid model for OpenSolaris, since > there is no effective difference between having a closed group > at Sun determine who the dictators shall be versus the Linux > method of having Linus Torvalds do the same. I should note, > however, that Linux would have failed miserably if Linus were > not such a nice guy that is respected by the entire community. > > So, I have to ask again: what is it that Sun wants in a governance > model for OpenSolaris? Do you want a collaborative model in which > outsiders are peers in the development process, or do you want > a hierarchical model in which outsiders merely contribute and hope > to obtain benefits from the process? Do you want this project to > be more like Linux or more like FreeBSD? > > I can write a governance process that works one way or the > other, but I will not write one that attempts to do both. > Dictators and collaborative development do not mix. Agreed on all points. Lets put this on the agenda for todays CAB call. Regards, Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 From John.Plocher at Sun.Com Wed Oct 12 09:44:30 2005 From: John.Plocher at Sun.Com (John Plocher) Date: Wed, 12 Oct 2005 09:44:30 -0700 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> Message-ID: <434D3D6E.6030207@Sun.Com> >>The model of development using a distributed SCM is for each >>individual or team to maintain its own branches and occasionally >>submit complete change sets to a higher-level individual managing >>a gateway for release. In general, there is no independent review >>of such changes until a merge/put-over is requested, at which time >>the benevolent dictator/gateway for the destination branch >>determines, possibly after consulting with others, whether or not >>the merge takes place. >> >>That model fits the development process at Sun today because >>there is a known hierarchy of Sun employees whose role is to act >>as a gateway manager according to the procedures set out by Sun. >> >>Coincidentally (or not), it is also the model that Linux uses >>for inclusion of code in the kernel, and what most of the Linux >>distros use for the rest of their operating systems as well >>(i.e., package maintainers as gateways). This is a flawed view of Sun's development model for Solaris. I agree, that if that *were* the proposed model, I would be uncomfortable with it as well - "gatekeeper as dictator" is an unacceptable state. Fortunately, this is not the case. The difference - as I wrote here on Aug 23 http://www.opensolaris.org/jive/thread.jspa?messageID=8058ὺ is that the "sun-style-gatekeeper" is not the hierarchical dictator as you might find in Linux et al. Instead, the role of decision maker is formalized into community based behaviors: 1) a general "do we want it?", managed entirely by the community and expressed as intent, policy or guidelines as needed. The suggested "three +1's and no -1's" is one such expression. 2) a specific "is this change architecturally acceptable?", managed by the architectural review committee(s) which are "staffed" entirely by community members, who perform peer review of the proposal. The role of the "sun-style-gatekeeper" is simply to ensure that all requested putbacks/commits have these two "approvals". The expected work flow follows this course time line: 1. An idea for germinates into something that a part of the community wishes to work on. 2. A proposal is generated that addresses the architectural/technical intent of the 3. The community determines whether or not the proposed fits within the norms of their community. 4. The ARC(s?) determine whether the proposal is acceptable; if not, it suggests/requires changes, or it denies the proposal completely. 5. Armed with the above "approvals", the project team goes off, creates a SCM branch to work with, does its development however it desires, tests it and does whatever is needed to complete the job it signed up to do. 6. When complete, the team selects a release branch to integrate into, and requests that its gatekeeper integrate their changes. If the team has obtained the above "approvals" and the release is in a state to accept the change (i.e., not in a formal release end-game...) the gatekeeper is obligated to integrate the change. 7. The team's branch is merged with the release branch, tested, and a new release is published. The team branch can be deleted, as it has no more function. The core difference, which I see as a "terminology" rather than "practice" disconnect, is the impact of where a branch is maintained. You seem to equate "distributed SCM" with pushing branch development out of the public view, with the only alternative of forcing all branch development to take place in a single centralized repository. I don't think that this matters much, as long as all the sub- communities that are working on O.S. things have a branch that is available in a place where they can all work on it together. > Such a > model assumes that key Sun engineers will be the gateways and > Sun ARCs will define the minimal criteria for gateway acceptance. I'd rewrite this: Such a model assumes that key _community_ engineers will be the gateways and _community staffed_ ARCs will define the minimal criteria for gateway acceptance. (of course, as we transition from "current status quo" to this future state, there will be a time at the beginning where the gatekeepers will be Sun engineers (Hi Danek!) and the ARCs will be staffed by Sun engineers (Hi PSARC!), but this *will* change) Your points about Apache (et al) are exactly my target as well: The collaborative model is safe for Sun because it has the effect of protecting everyone's most important interests (veto power on changes based on technical rationale) while treating everyone as peers. A hierarchical model in which outsiders merely contribute and hope to obtain benefits from the process is flawed and can not work. -John From kupfer at athyra.eng.sun.com Wed Oct 12 09:37:37 2005 From: kupfer at athyra.eng.sun.com (Mike Kupfer) Date: Wed, 12 Oct 2005 09:37:37 -0700 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: Message from Glynn Foster of "Wed, 12 Oct 2005 11:45:28 +1300." <1129070728.7865.496.camel@slipstream> Message-ID: <200510121637.j9CGbbLW012364@athyra.eng.sun.com> >>>>> "Glynn" == Glynn Foster writes: Roy> I think we have been given this as a requirement from Sun engineering Roy> without any consideration for its effect on governance. Glynn> Not to be too negative, but have we? I've seen zero requirements Glynn> being published out on the public lists, which I find personally Glynn> quite disappointing on such a wide reaching decision. Hmm, for some reason I was under the impression that a draft requirements list was yet to be sent out for comments. But anyway, I agree that the SCM requirements need discussion, including the question of centralized-vs-distributed. mike From cyril.plisko at gmail.com Wed Oct 12 10:14:50 2005 From: cyril.plisko at gmail.com (Cyril Plisko) Date: Wed, 12 Oct 2005 19:14:50 +0200 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: <434D3D6E.6030207@Sun.Com> References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> <434D3D6E.6030207@Sun.Com> Message-ID: On 10/12/05, John Plocher wrote: John, I understand that the flow below is your view of how tings suppose to work in OpenSolaris, right ? If so I quite disagree with you. See below: > > The expected work flow follows this course time line: > > 1. An idea for germinates into > something that a part of the community > wishes to work on. Naturally. > 2. A proposal is generated that addresses the > architectural/technical intent of the This may or may not be the case... Sometimes people just want to experiment in order to _get_ to proposals. They still however are part of the community and have a right for existance. > 3. The community determines whether or not the > proposed fits within the norms of > their community. That step is unneeded, IMHO. Community can come and go as needed. It should not be something with hard walls and boundaries. In any case the whole [special] community existance should have nothing to do with the development. And indeed it so today - look at UG community. > 4. The ARC(s?) determine whether the proposal > is acceptable; if not, it suggests/requires > changes, or it denies the proposal completely. That seems to be WAY to wrong to me. Do you really suggest that in order to develop something for OpenSolaris I need ARC (or whatever other comitee) approval ??? That may be the case for the Sun corporate environment, where engineering resources need to be quantified (since they are finite) and used wisely. However, in the open world no ARC can tell me what to do. Insisting on that role for ARC will only provocate forks and serve little good to the community at large. > 5. Armed with the above "approvals", the project > team goes off, creates a SCM branch to work > with, does its development however it desires, > tests it and does whatever is needed to complete > the job it signed up to do. Once again, what prevents me from doing it even today ? Without any ARC approval ? Heck, Polaris community did it already. So what's the point ? > 6. When complete, the team selects a release branch > to integrate into, and requests that its > gatekeeper integrate their changes. If the > team has obtained the above "approvals" and > the release is in a state to accept the change > (i.e., not in a formal release end-game...) > the gatekeeper is obligated to integrate the > change. That has to be different, since at this point intervention of ARC (or any other relevant comitee) may (should?) be required in order to determine the eligibility of the project integration into the main release. > 7. The team's branch is merged with the release > branch, tested, and a new release is published. > The team branch can be deleted, as it has no > more function. Right, no problems here :) I have overall impression that the whole model is an adaptation of the Sun' current scheme to a wider audience. I believe that it cannot go that way. You just cannot manage the community as a group of Sun employees. And if you'll create a a tough rules, people will leave. That should no happen. Regards, Cyril From al at logical-approach.com Wed Oct 12 11:23:58 2005 From: al at logical-approach.com (Al Hopper) Date: Wed, 12 Oct 2005 13:23:58 -0500 (CDT) Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> <434D3D6E.6030207@Sun.Com> Message-ID: On Wed, 12 Oct 2005, Cyril Plisko wrote: > On 10/12/05, John Plocher wrote: > John, > > I understand that the flow below is your view of how tings suppose > to work in OpenSolaris, right ? If so I quite disagree with you. > See below: > > > > > The expected work flow follows this course time line: > > > > 1. An idea for germinates into > > something that a part of the community > > wishes to work on. > > Naturally. > > > 2. A proposal is generated that addresses the > > architectural/technical intent of the > > This may or may not be the case... Sometimes people just > want to experiment in order to _get_ to proposals. > They still however are part of the community and have a right > for existance. > > > 3. The community determines whether or not the > > proposed fits within the norms of > > their community. > > That step is unneeded, IMHO. Community can come and go > as needed. It should not be something with hard walls and > boundaries. In any case the whole [special] community > existance should have nothing to do with the development. > And indeed it so today - look at UG community. > > > 4. The ARC(s?) determine whether the proposal > > is acceptable; if not, it suggests/requires > > changes, or it denies the proposal completely. > > That seems to be WAY to wrong to me. Do you really suggest > that in order to develop something for OpenSolaris I need > ARC (or whatever other comitee) approval ??? That may be > the case for the Sun corporate environment, where engineering > resources need to be quantified (since they are finite) and used > wisely. However, in the open world no ARC can tell me what to > do. Insisting on that role for ARC will only provocate forks and serve > little good to the community at large. There are a couple of points to be made here. a) This review is necessary only for someone who wants to see their work ultimately integrated into Solaris - the commercial project. If your intent is not to have the work integrated - then you don't need to bother with this. But ... see more below. b) If you do intend to see your work integrated into Solaris, the commercial distribution of OpenSolaris, then early review is intended to catch "silly" things like: - someone else is already 80% done with what you're proposing - someone else tried your (technical) approach before and found it not to work. So the ARC will tell you why it did'nt work and what was flawed with it. And possibly make available the associated email threads - or at least a sanitized version of them. - there is a design/architecture decision you've made that violates one of the Solaris core values, like, for example, backward compatibility etc. - there is a design decision you've made that is not compatible with the future direction of OpenSolaris - you've missed some key functionality that is necessary to integrate it successfully. For example, to support truss, or zones or DTrace or blah, blah. - you're suggesting a software architecture that might be fine in a userland application, but could cause not deterministic behavior in an OS kernel; or cause unexpected and objectionable response time hiccups to other applications etc. The early ARC review may also help you sharpen your development skills - becuase it'll allow you to tap into a bunch of engineering talent with a proven track record of success. Or prevent you from making a silly error by omission etc. --- topic change --- Three members of the CAB have been closely involved with the Development Process re-engineering efforts that have been a work in progress for several months now. That work is close to initial/draft publication, and I think, that when you see the entire process, and not a simplified summary of it that John P provided, it'll make more sense and be acceptable to the majority of serious OpenSolaris developers IMHO. I can understand your initial reaction to Johns email ... but please reserve judgement until you see the entire process. I think that you'll find that most of what that process describes is already being done by most serious developers. But many developers probably have not seen it written down, or formalized before. The intent is to help and not hinder the development process and to insure a painless integration of your work into Solaris - while maintaining the level of reliability, correctness and stability that Solaris is well known for. Don't forget that OpenSolaris members will be able to particpate at every point in the process. So .... please hang in there for a little longer until you see the entire development process published. I think it'll be a easy "sell" for most serious developers. > > 5. Armed with the above "approvals", the project > > team goes off, creates a SCM branch to work > > with, does its development however it desires, > > tests it and does whatever is needed to complete > > the job it signed up to do. > > Once again, what prevents me from doing it even today ? > Without any ARC approval ? Heck, Polaris community did > it already. So what's the point ? > > > 6. When complete, the team selects a release branch > > to integrate into, and requests that its > > gatekeeper integrate their changes. If the > > team has obtained the above "approvals" and > > the release is in a state to accept the change > > (i.e., not in a formal release end-game...) > > the gatekeeper is obligated to integrate the > > change. > > That has to be different, since at this point intervention of > ARC (or any other relevant comitee) may (should?) be required > in order to determine the eligibility of the project integration into the > main release. > > > > 7. The team's branch is merged with the release > > branch, tested, and a new release is published. > > The team branch can be deleted, as it has no > > more function. > > Right, no problems here :) > > > I have overall impression that the whole model is an adaptation > of the Sun' current scheme to a wider audience. I believe that > it cannot go that way. You just cannot manage the community > as a group of Sun employees. And if you'll create a a tough > rules, people will leave. That should no happen. > > > Regards, > Cyril > Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 From cyril.plisko at gmail.com Wed Oct 12 12:38:10 2005 From: cyril.plisko at gmail.com (Cyril Plisko) Date: Wed, 12 Oct 2005 21:38:10 +0200 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> <434D3D6E.6030207@Sun.Com> Message-ID: On 10/12/05, Al Hopper wrote: > On Wed, 12 Oct 2005, Cyril Plisko wrote: Al, I can see your point, however, I do have a couple of thoughts, See below: > > There are a couple of points to be made here. > > a) This review is necessary only for someone who wants to see their work > ultimately integrated into Solaris - the commercial project. If your > intent is not to have the work integrated - then you don't need to bother > with this. But ... see more below. > > b) If you do intend to see your work integrated into Solaris, the > commercial distribution of OpenSolaris, then early review is intended to > catch "silly" things like: That's quite a dangerous choice of wording, 'cause it sounds like Solaris as an OpenSolaris-based distribution is special compared to others. I am sure that was not your intention. > > - someone else is already 80% done with what you're proposing That shouldn't be ARC responsibility - for open source project that information should be available anyway. If Sun wants to brew some secret project without any community involvement (that's their right, of course) I wouldn't consider that case in the scope of OpenSolaris. Moreover, in such a case how can ARC or some other _community_ based committee be aware of such a project at all ? > - someone else tried your (technical) approach before and found it not to > work. So the ARC will tell you why it did'nt work and what was flawed with > it. And possibly make available the associated email threads - or at least > a sanitized version of them. > That's a valid point, however I'd (again) expect that info to be available anyway, right ? > - there is a design/architecture decision you've made that violates one of > the Solaris core values, like, for example, backward compatibility etc. > > - there is a design decision you've made that is not compatible with the > future direction of OpenSolaris > > - you've missed some key functionality that is necessary to integrate it > successfully. For example, to support truss, or zones or DTrace or blah, > blah. > > - you're suggesting a software architecture that might be fine in a > userland application, but could cause not deterministic behavior in an OS > kernel; or cause unexpected and objectionable response time hiccups to > other applications etc. All these should prevent the integration, not the work itself. > > The early ARC review may also help you sharpen your development skills - > becuase it'll allow you to tap into a bunch of engineering talent with a > proven track record of success. Or prevent you from making a silly error > by omission etc. That's why we have mailing lists/forums/etc, right ? Why do we need another committee to do this ? > > --- topic change --- > > Three members of the CAB have been closely involved with the Development > Process re-engineering efforts that have been a work in progress for > several months now. That work is close to initial/draft publication, and I > think, that when you see the entire process, and not a simplified summary > of it that John P provided, it'll make more sense and be acceptable to the > majority of serious OpenSolaris developers IMHO. Cool ! > > I can understand your initial reaction to Johns email ... but please > reserve judgement until you see the entire process. I think that you'll > find that most of what that process describes is already being done by most > serious developers. But many developers probably have not seen it written > down, or formalized before. > > > The intent is to help and not hinder the development process and to insure > a painless integration of your work into Solaris - while maintaining the > level of reliability, correctness and stability that Solaris is well known > for. > > Don't forget that OpenSolaris members will be able to particpate at every > point in the process. > > So .... please hang in there for a little longer until you see the entire > development process published. I think it'll be a easy "sell" for most > serious developers. > I will. Looking forward to see the doc. Regards, Cyril From rich.teer at rite-group.com Wed Oct 12 12:45:58 2005 From: rich.teer at rite-group.com (Rich Teer) Date: Wed, 12 Oct 2005 12:45:58 -0700 (PDT) Subject: [cab-discuss] OpenSolaris Charter: draft v2 In-Reply-To: <43471EF7.9000505@sun.com> References: <43471EF7.9000505@sun.com> Message-ID: On Fri, 7 Oct 2005, Jim Grisanzio wrote: Here's an example of what I was talking about (just in case I wasn't articulate enough): On January 25, 2005, Sun (1) opened the initial opensolaris.org web site, (2) announced that OpenSolaris would be released under the CDDL (Common Development and Distribution License), (3) released DTrace under that license, and (4) announced the intention to form a Community Advisory Board (CAB) of five members -- two Sun employees, two OpenSolaris Pilot Program participants elected by the community, and one open source community member. The five CAB members were introduced publicly on April 4, 2005, and OpenSolaris was officially launched on June 14, 2005. Next paragraph. Hope that clarifies what I was wittering on about! Cheers, -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich From Hugh.McIntyre at Sun.COM Wed Oct 12 14:27:20 2005 From: Hugh.McIntyre at Sun.COM (Hugh McIntyre) Date: Wed, 12 Oct 2005 14:27:20 -0700 (PDT) Subject: [cab-discuss] SCM and its effect on governance Message-ID: <0IO9008Y3NLK23@ha1sun-mail1.sfbay.sun.com> |> > b) If you do intend to see your work integrated into Solaris, the |> > commercial distribution of OpenSolaris, then early review is intended to |> > catch "silly" things like: |> |> That's quite a dangerous choice of wording, 'cause it sounds like Solaris |> as an OpenSolaris-based distribution is special compared to others. |> I am sure that was not your intention. IMHO at least it should say something like "want to get your code integrated to the main codebase on opensolaris.org". I.e. "into OpenSolaris", not "into Solaris" necessarily. |> > - someone else is already 80% done with what you're proposing |> |> That shouldn't be ARC responsibility - for open source project that |> information should be available anyway. |> |> > - someone else tried your (technical) approach before and found it not to |> > work. So the ARC will tell you why it did'nt work and what was flawed |> |> That's a valid point, however I'd (again) expect that info to be available |> anyway, right ? Not everybody knows everything. I.e. even if the information is publically available you may not have found it. I'm sure this already happens within Sun sometimes, so it's not an inside-versus-outside-Sun thing. Although the inside/outside problem makes this worse since clearly there's a bunch of historical information that's not public, now at least. This part of the process could mainly be thought of as a chance for a courtesy warning to warn people before they spend 6 months working on something and then find out at the end that it's already been done or that a lot of changes might be requested at the end. [*] If doing this via ARC seems too formal (maybe it is) think of this in terms of sending mail to the relevant community mailing list for comments instead. You can still work on the feature yourself if you don't like the comments, but it may help to avoid wasted time. Hugh. [*] One difference for OpenSolaris is that inside Sun if there is a team working on a project, there's presumably an assumption (in general at least) that the project will be done as promised. Whereas not every external developer is working on things full time (or is paid), so just because someone else is working on a project does not guarantee it will get finished. I.e. just because you get told "someone else is already 80% done" does not mean you can't work on it. From John.Plocher at Sun.Com Wed Oct 12 14:36:55 2005 From: John.Plocher at Sun.Com (John Plocher) Date: Wed, 12 Oct 2005 14:36:55 -0700 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: References: <83a30411dc523cc5aace0c32dfdc5499@gbiv.com> <434D3D6E.6030207@Sun.Com> Message-ID: <434D81F7.9010706@Sun.Com> [I want to amplify Al's comment that the intent of all this is to help and not hinder the development process and to insure a painless integration of your work into [Open]Solaris - John] Cyril Plisko wrote: >> John Plocher wrote: >> 2. A proposal is generated that addresses the >> architectural/technical intent of the > > > This may or may not be the case... Sometimes people just > want to experiment in order to _get_ to proposals. I probably should have prefaced this all with a few assumptions: "This is for projects that wish to integrate back into OpenSolaris, and does not affect any private tinkering or investigation done without that intent" - and - "at some point, with zero or more tinkering and prototyping, an idea will germinate into a proposal. How exactly that happens is out of scope for this discussion." > They still however are part of the community and have a right > for existence. Right, but. :-) The "but" is they don't have a right to be integrated back into the community's source tree until and unless the community wants it. This is not anarchy. One of the benefits of a distributed SCM environment is that anyone can create their own branch, play with it however they wish, and relatively effortlessly keep it in sync and up to date with the community. >> 3. The community determines whether or not the >> proposed fits within the norms of >> their community. > > > That step is unneeded, IMHO. Community can come and go > as needed. It should not be something with hard walls and > boundaries. In any case the whole [special] community > existance should have nothing to do with the development. > And indeed it so today - look at UG community. Glossary overload. Does Community := OpenSolaris or does community := "some discussion forum" or ...? In the governance proposal, there is postulated a community that is self-responsible for its work-product. The above is simply restating that point for things that intend to go back into the official source tree. It obviously does not apply for things that don't so intend. >> 4. The ARC(s?) determine whether the proposal >> is acceptable; if not, it suggests/requires >> changes, or it denies the proposal completely. > > That seems to be WAY to wrong to me. Do you really suggest > that in order to develop something for OpenSolaris I need > ARC (or whatever other comitee) approval??? No, not at all - for development. Rather, if you intend to incorporate the result INTO OpenSolaris, the community needs to understand and approve the impact - if any. Things that don't impact the architecture of the system obviously don't need architectural review. This means that for 80+% of things, this step turns into a NOOP. For the other 20%, it is much better to do this interaction early (when there is still a chance to influence the effort), rather than at the point of integration when there isn't. > That may be > the case for the Sun corporate environment, where engineering > resources need to be quantified (since they are finite) and used This isn't a resource allocation issue at all - it is a "develop software by intent rather than by accident" one. > wisely. However, in the open world no ARC can tell me what to > do. Insisting on that role for ARC will only provocate forks and serve > little good to the community at large. Right - the ARCs don't exist to tell you what you can or can't work on, but rather they exist to help you figure out what architectural constraints or challenges your efforts will face if/when they integrate back into the main source tree. For example: Suppose you want to gratuitously change the open() call in libc in such a way that would break all existing programs. You can work on this effort as much as you want, but you _should_ face difficulties if/when you attempt to integrate the change back into OpenSolaris. It is the role of the community architects (aka ARC members) to manage the evolution of the system. > Once again, what prevents me from doing it even today ? > Without any ARC approval ? Heck, Polaris community did > it already. So what's the point ? If you want the OpenSolaris community to incorporate your changes into the official OpenSolaris source base... > I have overall impression that the whole model is an adaptation > of the Sun' current scheme to a wider audience. Certainly - this is the process that gives Solaris the stability and predictability that is valued by Sun and its customers. IMHO, it would be foolish to abandon that process and let OpenSolaris devolve into a more chaotic system. (It would also be foolish to force Sun's existing system on the community, or to assume that such a process should be static and not evolve over time...) > And if you'll create a a tough > rules, people will leave. That should no happen. One of the differentiators of the OpenSolaris community is that it values reliability, correctness and stability; attributes that come directly from the development process used. As Al said, please hang in there... -John From al at logical-approach.com Wed Oct 12 18:06:46 2005 From: al at logical-approach.com (Al Hopper) Date: Wed, 12 Oct 2005 20:06:46 -0500 (CDT) Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: <0IO9008Y3NLK23@ha1sun-mail1.sfbay.sun.com> References: <0IO9008Y3NLK23@ha1sun-mail1.sfbay.sun.com> Message-ID: On Wed, 12 Oct 2005, Hugh McIntyre wrote: > > |> > b) If you do intend to see your work integrated into Solaris, the > |> > commercial distribution of OpenSolaris, then early review is intended to > |> > catch "silly" things like: > |> > |> That's quite a dangerous choice of wording, 'cause it sounds like Solaris > |> as an OpenSolaris-based distribution is special compared to others. > |> I am sure that was not your intention. > > IMHO at least it should say something like "want to get your code integrated to > the main codebase on opensolaris.org". I.e. "into OpenSolaris", not "into > Solaris" necessarily. Agreed. It was poorly worded. I was in the middle of about 3 things when I saw the post and made an effort to respond to it ASAP. > |> > - someone else is already 80% done with what you're proposing > |> > |> That shouldn't be ARC responsibility - for open source project that > |> information should be available anyway. > |> > |> > - someone else tried your (technical) approach before and found it not to > |> > work. So the ARC will tell you why it did'nt work and what was flawed > |> > |> That's a valid point, however I'd (again) expect that info to be available > |> anyway, right ? > > Not everybody knows everything. I.e. even if the information is publically > available you may not have found it. I'm sure this already happens within Sun > sometimes, so it's not an inside-versus-outside-Sun thing. Although the > inside/outside problem makes this worse since clearly there's a bunch of > historical information that's not public, now at least. Its easy to understand when you have a complex set of related software systems that are used to manage very large software development projects and the concept of going public at some point in the future was never considered. Since these tools also manage client/customer/partner data and data related to new products/projects, you can easily see that its almost impossible to "split the baby". > This part of the process could mainly be thought of as a chance for a courtesy > warning to warn people before they spend 6 months working on something and then > find out at the end that it's already been done or that a lot of changes might > be requested at the end. [*] > > If doing this via ARC seems too formal (maybe it is) think of this in terms of > sending mail to the relevant community mailing list for comments instead. You > can still work on the feature yourself if you don't like the comments, but it > may help to avoid wasted time. > > Hugh. > > [*] One difference for OpenSolaris is that inside Sun if there is a team working > on a project, there's presumably an assumption (in general at least) that the > project will be done as promised. Whereas not every external developer is > working on things full time (or is paid), so just because someone else is > working on a project does not guarantee it will get finished. I.e. just because > you get told "someone else is already 80% done" does not mean you can't work on > it. > Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 From Jim.Grisanzio at Sun.COM Fri Oct 14 13:17:04 2005 From: Jim.Grisanzio at Sun.COM (Jim Grisanzio) Date: Fri, 14 Oct 2005 13:17:04 -0700 Subject: [cab-discuss] CAB Meeting Notes: Wed Oct 12 Message-ID: <43501240.5070804@sun.com> Below are notes from the CAB meeting this past Wednesday. Jim --- Jim Grisanzio, Community Manager, OpenSolaris http://blogs.sun.com/jimgris/ CAB Meeting Notes: Oct 12, 2005 CAB members present: Al Hopper, Simon Phipps, Rich Teer, Roy Fielding CAB correspondent: Jim Grisanzio The CAB discussed primarily two issues during this call: (1) source code management based on Roy's post (http://www.opensolaris.org/jive/thread.jspa?threadID=2806&tstart=0) and (2) the OpenSolaris Charter draft SCM: There is concern that Sun's SCM decisions are being made without involving the external community enough. Sun has posted information about SCM (http://www.opensolaris.org/jive/thread.jspa?threadID=2174&tstart=0), and there has been SCM discussion at various times throughout the project -- including the joint CAB/dev-process team meetings at OSCON in Portland -- but there is concern that the issue is not moving fast enough (or open enough) to resolution. There has been recent conversation on the CAB's list to this effect. The CAB will wait before moving forward on Governance conversations because the Governance needs to be consistent with the co-development processes, a draft of which will be posted to the community in the near future. The OpenSolaris Charter: The CAB gave feedback on v2 of the OpenSolaris Charter -- basic copy editing/readability changes, putting the core values back in, adding a paragraph about the OpenSolaris mission to clarify what OpenSolaris is, etc. Jim will make these changes and circulate another draft. Jim From Jim.Grisanzio at Sun.COM Fri Oct 14 13:21:10 2005 From: Jim.Grisanzio at Sun.COM (Jim Grisanzio) Date: Fri, 14 Oct 2005 13:21:10 -0700 Subject: [cab-discuss] OpenSolaris Charter: draft v2.1 Message-ID: <43501336.3060203@sun.com> I updated the OpenSolaris Charter based on the CAB's feedback from the meeting this week. I added the core values and community mission statement and reworked the intro a bit. Made several copy edits throughout. Jim --- Jim Grisanzio, Community Manager, OpenSolaris http://blogs.sun.com/jimgris/ The OpenSolaris Charter (10/14/05 draft v2.1) Introduction The OpenSolaris Charter is the title and deed that Sun Microsystems, Inc. has transferred to the OpenSolaris community. Although Sun currently sponsors the OpenSolaris project, the OpenSolaris Governing Board (OGB) is now the body that holds the OpenSolaris Charter, represents the community, and specifies how decisions are made on the project through the OpenSolaris Governance. The OpenSolaris Community Mission The OpenSolaris Project represents an active community of developers and users collaborating to improve the OpenSolaris source base on opensolaris.org. The community's core values -- openness, inclusiveness, respect, honesty, quality, and independence -- will always be clearly reflected in how the community and its leaders behave and will help guide the community as it evolves the OpenSolaris technology. History of the OpenSolaris Project In early 2004, Sun initiated the project to open source the Solaris operating system. A multi-disciplinary team was formed to consider all the aspects of the project: licensing, business model, governance, co-development, source code analysis, source code management, tools, marketing, and community development. A pilot program was formed in September of 2004 with 18 non-Sun community members and ran for 9 months growing to 145 external participants. On January 25, 2005, Sun began the formal public phase of opening the project by initiating the following actions: (1) opening the first phase of the opensolaris.org web site, (2) announcing that OpenSolaris would be released under the CDDL (Common Development and Distribution License), (3) releasing the DTrace source under CDDL, and (4) announcing the intention to form a Community Advisory Board (CAB) of five members -- two Sun employees, two OpenSolaris Pilot Program participants elected by the community, and one open source community member. The five CAB members were introduced publicly on April 4, 2005, and OpenSolaris was officially launched on June 14, 2005. When the CAB was formed, Sun requested that the group write two critical documents: (1) a Charter detailing a governing board's scope and (2) a Governance outlining how the OpenSolaris community would function. Sun's intention was to not only open the Solaris source code, but to also transfer the operations, stewardship, and management of the project to the OpenSolaris community -- which is now represented by the OGB. OGB Mission Statement The OGB provides formal representation and structure for the OpenSolaris community via the OpenSolaris Charter and the OpenSolaris Governance. OGB members will always act on behalf of the OpenSolaris community and honor the community's values in every way possible. OGB Scope The scope of the OGB covers anything related to the OpenSolaris project. In this context, scope means that the OGB has the authority to get involved in all aspects of the project to ensure that the community is properly represented. Management of the OpenSolaris project -- including the source code and its evolution -- is now under the control of the OpenSolaris community. That community includes the OpenSolaris developers, system administrators, users, evangelists, and marketers involved with the project, and their roles are outlined by the OpenSolaris Governance. The OGB gets involved when there are disputes or when there are new issues to be devised. OpenSolaris Governing Board Elections The OGB consists of seven members who are elected by OpenSolaris community members with voting privileges as defined in the OpenSolaris Governance. A quorum of five OGB members will be required to make significant changes to any of the OpenSolaris governing documents and those documents will have to be ratified by the community. OGB candidates are OpenSolaris members in good standing, nominated by the OpenSolaris membership, and must accept the nomination to be considered. The voting process is the Single Transferable Vote (STV). Elections are held once a year on the anniversary of the formation of the first OGB. There are no term limits. Board members will not be assigned specific functions. If a board member resigns or is otherwise unable to complete his or her term, the next runner-up in the election will fill that position. There is no termination from the Board other than by resignation within a term. The board may, at its discretion and with a quorum of 5 OGB members, decide to dissolve itself to force a new election. Single Transferable Vote OGB members are elected by "Single Transferable Vote" as described at: http://www.electoral-reform.org.uk/votingsystems/stvi.htm http://www.cix.co.uk/~rosenstiel/stvrules/index.htm http://stv.sourceforge.net/ To summarize, each member has one vote, but it is cast as an ordered list of preferred candidates. A later preference is considered only if an earlier preference has a surplus above the quota required for election or is excluded because of insufficient support. Under no circumstances will a later preference count against an earlier preference. The effect of STV is to balance representation across all significant groups in the community. Legal Status The OGB operates within the scope of this Charter and is not an independent legal entity. Sun is the lead copyright holder of the OpenSolaris code, and any legal disputes are resolved by Sun. Community Costs At this time, Sun has agreed to fund the OpenSolaris project, which includes all the infrastructure, the website, the source code management system and related build and package management tools, marketing and community development functions, and the administrative costs of the OGB (including travel expenses for two OGB meetings a year). - End - From Jim.Grisanzio at Sun.COM Fri Oct 14 17:39:44 2005 From: Jim.Grisanzio at Sun.COM (Jim Grisanzio) Date: Fri, 14 Oct 2005 17:39:44 -0700 Subject: [cab-discuss] OpenSolaris Charter: draft v2 In-Reply-To: <434CE017.7040706@cuddletech.com> References: <43471EF7.9000505@sun.com> <434CE017.7040706@cuddletech.com> Message-ID: <43504FD0.7020203@sun.com> Ben Rockwood wrote: > Indeed, good job Jim. > > Pushing out a release candidate would be great. I still have problems > with the charter (all mentioned in the past, still unresolved in my > mind) but I think an RC will give us something to really start chewing > on and getting people interested since we're moving toward a result. > I'm looking forward to getting a much larger audience involved around > the charter. Chew on it now, Ben. Feel free (but do it on draft v2.1 I just sent today). The time for comment is now ... before it is submitted to Sun for final approval. Jim -- Jim Grisanzio, Community Manager, OpenSolaris http://blogs.sun.com/jimgris/ From Glynn.Foster at Sun.COM Fri Oct 14 18:24:18 2005 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Sat, 15 Oct 2005 14:24:18 +1300 Subject: [cab-discuss] OpenSolaris Charter: draft v2.1 In-Reply-To: <43501336.3060203@sun.com> References: <43501336.3060203@sun.com> Message-ID: <1129339459.7865.788.camel@slipstream> Hey, So one thing that does worry me slightly from a corporate point of view, and as much about creating a community of open communication is the following - > OpenSolaris Governing Board Elections > > The OGB consists of seven members who are elected by OpenSolaris > community members with voting privileges as defined in the OpenSolaris > Governance. A quorum of five OGB members will be required to make > significant changes to any of the OpenSolaris governing documents and > those documents will have to be ratified by the community. OGB > candidates are OpenSolaris members in good standing, nominated by the > OpenSolaris membership, and must accept the nomination to be considered. > The voting process is the Single Transferable Vote (STV). Elections are > held once a year on the anniversary of the formation of the first OGB. > There are no term limits. Obviously there's no requirement for any of the 7 OGB members to work for Sun. While I certainly welcome that trust to build up a community of responsible contributors, I just wonder if that could cause potential communication problems further down the line? I'm actually half surprised I'm suggesting this, but it feels like *at least one* person should be working for Sun in some sort of capacity. > To summarize, each member has one vote, but it is cast as an ordered > list of preferred candidates. A later preference is considered only if > an earlier preference has a surplus above the quota required for > election or is excluded because of insufficient support. Under no > circumstances will a later preference count against an earlier > preference. The effect of STV is to balance representation across all > significant groups in the community. I notice this charter doesn't mention anything about the OpenSolaris membership, and how that might work. I know this is potentially a task for the initial OGB to come up with, but I think we should be more explicit about it. Otherwise, the doc looks great - thanks Jim! Glynn From webmink at sun.com Fri Oct 14 20:14:15 2005 From: webmink at sun.com (Simon Phipps) Date: Sat, 15 Oct 2005 04:14:15 +0100 Subject: [cab-discuss] OpenSolaris Charter: draft v2.1 In-Reply-To: <1129339459.7865.788.camel@slipstream> References: <43501336.3060203@sun.com> <1129339459.7865.788.camel@slipstream> Message-ID: <963582E9-FAAF-4BA6-A138-2F92AA092B5D@sun.com> Thanks for the feedback. On Oct 15, 2005, at 02:24, Glynn Foster wrote: > Hey, > > So one thing that does worry me slightly from a corporate point of > view, > and as much about creating a community of open communication is the > following - > > > >> OpenSolaris Governing Board Elections >> >> The OGB consists of seven members who are elected by OpenSolaris >> community members with voting privileges as defined in the >> OpenSolaris >> Governance. A quorum of five OGB members will be required to make >> significant changes to any of the OpenSolaris governing documents and >> those documents will have to be ratified by the community. OGB >> candidates are OpenSolaris members in good standing, nominated by the >> OpenSolaris membership, and must accept the nomination to be >> considered. >> The voting process is the Single Transferable Vote (STV). >> Elections are >> held once a year on the anniversary of the formation of the first >> OGB. >> There are no term limits. >> >> > > Obviously there's no requirement for any of the 7 OGB members to work > for Sun. While I certainly welcome that trust to build up a > community of > responsible contributors, I just wonder if that could cause potential > communication problems further down the line? I'm actually half > surprised I'm suggesting this, but it feels like *at least one* person > should be working for Sun in some sort of capacity. > My view is that the nature of the electorate, containing as it does mainly Sun employees, will mean that it would be a shocking indictment of Sun if at least one member were not a Sun employee. I am actually more worried there will be no /non/ Sun employees elected. I think this point merits discussion and I'd welcome people's thoughts. I am not keen to have quotas but if it's essential we'll have to do it. > > >> To summarize, each member has one vote, but it is cast as an ordered >> list of preferred candidates. A later preference is considered >> only if >> an earlier preference has a surplus above the quota required for >> election or is excluded because of insufficient support. Under no >> circumstances will a later preference count against an earlier >> preference. The effect of STV is to balance representation across all >> significant groups in the community. >> >> > > I notice this charter doesn't mention anything about the OpenSolaris > membership, and how that might work. I know this is potentially a task > for the initial OGB to come up with, but I think we should be more > explicit about it. > It will be defined explicitly in the Governance, by the CAB, before the OGB is elected under the terms of the new Governance. S. From sommerfeld at sun.com Fri Oct 14 20:37:18 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Fri, 14 Oct 2005 23:37:18 -0400 Subject: [cab-discuss] OpenSolaris Charter: draft v2.1 In-Reply-To: <1129339459.7865.788.camel@slipstream> References: <43501336.3060203@sun.com> <1129339459.7865.788.camel@slipstream> Message-ID: <1129347437.2260.252.camel@thunk> On Fri, 2005-10-14 at 21:24, Glynn Foster wrote: > I'm actually half > surprised I'm suggesting this, but it feels like *at least one* person > should be working for Sun in some sort of capacity. someone serving as an official liason to sun from the OGB need not have a vote on that board. - Bill From Karyn.Ritter at Sun.COM Sun Oct 16 20:46:19 2005 From: Karyn.Ritter at Sun.COM (Karyn Ritter) Date: Sun, 16 Oct 2005 20:46:19 -0700 Subject: [cab-discuss] OpenSolaris Charter: draft v2.1 In-Reply-To: <43501336.3060203@sun.com> References: <43501336.3060203@sun.com> Message-ID: <43531E8B.5000104@sun.com> My belief is that this document basically enfranchises the OGB and lays the groundwork for the governance model. If I've got that completely wrong, I'm sure you all will tell me. My hope is that it will at least provide some context for my questions and comments below. I'd like to say first that I think you all have a hard job writing this document. My inclination would be to leverage charters from other open source projects, but I'm not sure that is appropriate since, unlike many other projects, this is not a separate foundation... Jim Grisanzio wrote: > I updated the OpenSolaris Charter based on the CAB's feedback from the > meeting this week. I added the core values and community mission > statement and reworked the intro a bit. Made several copy edits throughout. > > Jim > --- > Jim Grisanzio, Community Manager, OpenSolaris > http://blogs.sun.com/jimgris/ > > > > > The OpenSolaris Charter > (10/14/05 draft v2.1) > > > Introduction > > The OpenSolaris Charter is the title and deed that Sun Microsystems, > Inc. has transferred to the OpenSolaris community. Although Sun > currently sponsors the OpenSolaris project, the OpenSolaris Governing > Board (OGB) is now the body that holds the OpenSolaris Charter, > represents the community, and specifies how decisions are made on the > project through the OpenSolaris Governance. > What does this mean exactly? What is the "title and deed" that has been transferred, and to whom? To me, this reads like Sun has transferred something to an independent, legal entity, but that isn't the case. Perhaps saying something more akin to: The OpenSolaris Governing Board (OGB), representing the OpenSolaris community, is the body specifying how decisions are made for the OpenSolaris project. The OGB specifies these decision-making mechanisms through the OpenSolaris Charter and Governance. I doubt that what I've written works, but I wonder if it is clearer. I'm sure you all will chime in and say one way or another. :) > The OpenSolaris Community Mission > > The OpenSolaris Project represents an active community of developers and > users collaborating to improve the OpenSolaris source base on > opensolaris.org. The community's core values -- openness, inclusiveness, > respect, honesty, quality, and independence -- will always be clearly > reflected in how the community and its leaders behave and will help > guide the community as it evolves the OpenSolaris technology. > I think the OpenSolaris Community Mission and OGB Mission should be combined into one OGB Mission statement: The OGB provides formal representation and structure for the OpenSolaris community of developers and users via the OpenSolaris Charter and the OpenSolaris Governance. OGB members will always act on behalf of the OpenSolaris community, and in every way possible will honor the community's values: openness, inclusiveness, respect, honesty, quality and independence. Maybe it's just me, but I think these need to be connected since this is the OGB charter. > > History of the OpenSolaris Project > > In early 2004, Sun initiated the project to open source the Solaris > operating system. A multi-disciplinary team was formed to consider all > the aspects of the project: licensing, business model, governance, > co-development, source code analysis, source code management, tools, > marketing, and community development. A pilot program was formed in > September of 2004 with 18 non-Sun community members and ran for 9 months > growing to 145 external participants. > > On January 25, 2005, Sun began the formal public phase of opening the > project by initiating the following actions: > > (1) opening the first phase of the opensolaris.org web site, > (2) announcing that OpenSolaris would be released under the CDDL (Common > Development and Distribution License), > (3) releasing the DTrace source under CDDL, and > (4) announcing the intention to form a Community Advisory Board (CAB) of > five members -- two Sun employees, two OpenSolaris Pilot Program > participants elected by the community, and one open source community > member. > > The five CAB members were introduced publicly on April 4, 2005, and > OpenSolaris was officially launched on June 14, 2005. > > When the CAB was formed, Sun requested that the group write two critical > documents: > > (1) a Charter detailing a governing board's scope and > (2) a Governance outlining how the OpenSolaris community would function. > > Sun's intention was to not only open the Solaris source code, but to > also transfer the operations, stewardship, and management of the project > to the OpenSolaris community -- which is now represented by the OGB. > > > OGB Mission Statement > > The OGB provides formal representation and structure for the OpenSolaris > community via the OpenSolaris Charter and the OpenSolaris Governance. > OGB members will always act on behalf of the OpenSolaris community and > honor the community's values in every way possible. > > > OGB Scope > > The scope of the OGB covers anything related to the OpenSolaris project. > In this context, scope means that the OGB has the authority to get > involved in all aspects of the project to ensure that the community is > properly represented. Management of the OpenSolaris project -- including > the source code and its evolution -- is now under the control of the > OpenSolaris community. That community includes the OpenSolaris > developers, system administrators, users, evangelists, and marketers > involved with the project, and their roles are outlined by the > OpenSolaris Governance. The OGB gets involved when there are disputes or > when there are new issues to be devised. > To me the above read vaguely. Re-reading it a few times, I'm wondering if just moving some sentences around makes it clearer: Management of the OpenSolaris project -- including the source code and its evolution -- is now under the control of the OpenSolaris community. That community includes the OpenSolaris developers, system administrators, users, evangelists, and marketers involved with the project, and their roles are outlined by the OpenSolaris Governance. This community is formally represented by the OGB. The OGB has the authority to get involved in all aspects of the OpenSolaris project to ensure that the community is properly represented. The OGB gets involved when there are disputes or when there are new issues to be devised. I don't know if that helps... When I first read the statement it was unclear how, when, and why the OGB would get involved in resolving issues. My only issue with the content above is that Sun hasn't completely given the management of the OpenSolaris project over to the community yet (e.g., the main source trees are not being controlled and managed outside of Sun's internal network). We should factor in that there are plenty of Sun people in the community, but it still isn't true yet. Not sure if that matters for the purposes of this document. Perhaps if it is changed to: Sun's intent is to give management of the OpenSolaris project -- including the source code and its evolution -- to the OpenSolaris community. > > OpenSolaris Governing Board Elections > > The OGB consists of seven members who are elected by OpenSolaris > community members with voting privileges as defined in the OpenSolaris > Governance. A quorum of five OGB members will be required to make > significant changes to any of the OpenSolaris governing documents and > those documents will have to be ratified by the community. OGB > candidates are OpenSolaris members in good standing, nominated by the > OpenSolaris membership, and must accept the nomination to be considered. > The voting process is the Single Transferable Vote (STV). Elections are > held once a year on the anniversary of the formation of the first OGB. > There are no term limits. > > Board members will not be assigned specific functions. If a board member > resigns or is otherwise unable to complete his or her term, the next > runner-up in the election will fill that position. There is no > termination from the Board other than by resignation within a term. The > board may, at its discretion and with a quorum of 5 OGB members, decide > to dissolve itself to force a new election. > > > Single Transferable Vote > > OGB members are elected by "Single Transferable Vote" as described at: > > http://www.electoral-reform.org.uk/votingsystems/stvi.htm > http://www.cix.co.uk/~rosenstiel/stvrules/index.htm > http://stv.sourceforge.net/ > > To summarize, each member has one vote, but it is cast as an ordered > list of preferred candidates. A later preference is considered only if > an earlier preference has a surplus above the quota required for > election or is excluded because of insufficient support. Under no > circumstances will a later preference count against an earlier > preference. The effect of STV is to balance representation across all > significant groups in the community. > I still didn't get what SVT meant after reading the above. Looking at the sites above, I didn't see a concise explanation that could be easily copied and put in place here. Perhaps someone else can take a stab? I understand it a bit more now, but not enough to propose something. :) > > Legal Status > > The OGB operates within the scope of this Charter and is not an > independent legal entity. Sun is the lead copyright holder of the > OpenSolaris code, and any legal disputes are resolved by Sun. > > > Community Costs > > At this time, Sun has agreed to fund the OpenSolaris project, which > includes all the infrastructure, the website, the source code management > system and related build and package management tools, marketing and > community development functions, and the administrative costs of the OGB > (including travel expenses for two OGB meetings a year). > The only thing I worry about here is contention later about what agreements have been reached about Sun's funding of the OGB. Perhaps saying something like: Sun's primary funding of the OpenSolaris project to date covers resources (personnel, hardware/software, and program dollars) for the infrastructure, website, source code management system, related build and package management tools, marketing, and community development functions. In addition, Sun will cover administrative costs of the OGB in terms of travel expenses for 2 OGB meetings/year, ... I don't know that we need to get overly specific. I just want everyone's expectations to be set appropriately for what Sun will and will not pay for. I would hate for the OGB to assume that certain things fall under the heading of "administrative costs" only to find out that Sun does not agree to cover them. I just don't want there to be any misunderstandings. Thanks! Karyn From Karyn.Ritter at Sun.COM Sun Oct 16 22:00:26 2005 From: Karyn.Ritter at Sun.COM (Karyn Ritter) Date: Sun, 16 Oct 2005 22:00:26 -0700 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: References: <0IO9008Y3NLK23@ha1sun-mail1.sfbay.sun.com> Message-ID: <43532FEA.1000405@sun.com> Thanks to everyone who responded to this thread. I hope people like Hugh helped to allay some of the fears being expressed. Stephen Hahn has been out of the office, and I'm not sure if he'll jump in on this when he returns. In any case, there are a couple of things I wanted to mention: 1. A "distributed source code management system" describes the type of functionality we've found essential to managing a large source base with so many developers. This kind of system allows developers to make and test large- or small-scale changes without destabilizing the main source tree. In the end it all comes back into the main source tree, and others have done a good job describing the way our gatekeeping system works. Without listening to lengthy process descriptions like the ones Al and Rich have participated in, it may be difficult to understand that Sun/Solaris doesn't have a dictator: benevolent or otherwise. 2. The requirements for making a decision about a distributed source code management system have not yet been proposed. Stephen Hahn will absolutely send the initial requirements list out to the community, and have the discussion in the public. There is no "black op" happening here. We're just not moving as quickly as we'd like. Perhaps you all can give us some ideas about how best to keep the community informed about our progress (or lackthereof). 3. It is my belief that the governance model can be written without any further guidance from Sun. The CAB should write what they think is best for the OpenSolaris community, and then it is up to the community and Sun to ratify it. Thanks, Karyn Al Hopper wrote: > On Wed, 12 Oct 2005, Hugh McIntyre wrote: > > >>|> > b) If you do intend to see your work integrated into Solaris, the >>|> > commercial distribution of OpenSolaris, then early review is intended to >>|> > catch "silly" things like: >>|> >>|> That's quite a dangerous choice of wording, 'cause it sounds like Solaris >>|> as an OpenSolaris-based distribution is special compared to others. >>|> I am sure that was not your intention. >> >>IMHO at least it should say something like "want to get your code integrated to >>the main codebase on opensolaris.org". I.e. "into OpenSolaris", not "into >>Solaris" necessarily. > > > Agreed. It was poorly worded. I was in the middle of about 3 things when > I saw the post and made an effort to respond to it ASAP. > > >>|> > - someone else is already 80% done with what you're proposing >>|> >>|> That shouldn't be ARC responsibility - for open source project that >>|> information should be available anyway. >>|> >>|> > - someone else tried your (technical) approach before and found it not to >>|> > work. So the ARC will tell you why it did'nt work and what was flawed >>|> >>|> That's a valid point, however I'd (again) expect that info to be available >>|> anyway, right ? >> >>Not everybody knows everything. I.e. even if the information is publically >>available you may not have found it. I'm sure this already happens within Sun >>sometimes, so it's not an inside-versus-outside-Sun thing. Although the >>inside/outside problem makes this worse since clearly there's a bunch of >>historical information that's not public, now at least. > > > Its easy to understand when you have a complex set of related software > systems that are used to manage very large software development projects > and the concept of going public at some point in the future was never > considered. Since these tools also manage client/customer/partner data and > data related to new products/projects, you can easily see that its almost > impossible to "split the baby". > > >>This part of the process could mainly be thought of as a chance for a courtesy >>warning to warn people before they spend 6 months working on something and then >>find out at the end that it's already been done or that a lot of changes might >>be requested at the end. [*] >> >>If doing this via ARC seems too formal (maybe it is) think of this in terms of >>sending mail to the relevant community mailing list for comments instead. You >>can still work on the feature yourself if you don't like the comments, but it >>may help to avoid wasted time. >> >>Hugh. >> >>[*] One difference for OpenSolaris is that inside Sun if there is a team working >>on a project, there's presumably an assumption (in general at least) that the >>project will be done as promised. Whereas not every external developer is >>working on things full time (or is paid), so just because someone else is >>working on a project does not guarantee it will get finished. I.e. just because >>you get told "someone else is already 80% done" does not mean you can't work on >>it. >> > > > Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com > Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT > OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 > _______________________________________________ > cab-discuss mailing list > cab-discuss at opensolaris.org From john.plocher at sun.com Mon Oct 17 10:15:14 2005 From: john.plocher at sun.com (John Plocher) Date: Mon, 17 Oct 2005 10:15:14 -0700 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: <43532FEA.1000405@sun.com> References: <0IO9008Y3NLK23@ha1sun-mail1.sfbay.sun.com> <43532FEA.1000405@sun.com> Message-ID: <4353DC22.7010601@sun.com> Karyn Ritter wrote > 3. It is my belief that the governance model can be written without > any further guidance from Sun. IMHO, you might want to make a distinction between "Sun as a corporate entity" and "Sun employees who are members of this community". If you meant the former: +1 If you meant ther latter, -1 - nothing in this community's DNA should prevent Sun employees from being first class members - we should not set up a system (of rules, expectations or assumptions) where external voices are somehow different than internal ones. We all are community members, and we honor openness and inclusiveness. > The CAB should write what they > think is best for the OpenSolaris community, and then it is up to > the community and Sun to ratify it. The CAB shouldn't be expected to invent stuff that doesn't reflect the community - a model of "we control the content, all you can do is say yes or no, without an ability to influence it" would be a bad thing - fortunately, the CAB isn't operating that way. -John Plocher From kritter at eng.sun.com Mon Oct 17 10:19:23 2005 From: kritter at eng.sun.com (Karyn Ritter) Date: Mon, 17 Oct 2005 10:19:23 -0700 Subject: [cab-discuss] SCM and its effect on governance In-Reply-To: <4353DC22.7010601@sun.com> References: <0IO9008Y3NLK23@ha1sun-mail1.sfbay.sun.com> <43532FEA.1000405@sun.com> <4353DC22.7010601@sun.com> Message-ID: <4353DD1B.3090009@eng.sun.com> John Plocher wrote: > Karyn Ritter wrote > >> 3. It is my belief that the governance model can be written without >> any further guidance from Sun. > > > IMHO, you might want to make a distinction between "Sun as a corporate > entity" and "Sun employees who are members of this community". > > If you meant the former: +1 > Yes, this is what I meant. I was responding to Roy's comment that Sun needed to provide guidance about what we want before the CAB can write the governance proposal. Thanks, Karyn > If you meant ther latter, -1 - nothing in this community's DNA should > prevent Sun employees from being first class members - we should not > set up a system (of rules, expectations or assumptions) where external > voices are somehow different than internal ones. We all are community > members, and we honor openness and inclusiveness. > >> The CAB should write what they >> think is best for the OpenSolaris community, and then it is up to >> the community and Sun to ratify it. > > > The CAB shouldn't be expected to invent stuff that doesn't reflect the > community - a model of > "we control the content, all you can do is say yes or no, > without an ability to influence it" > would be a bad thing - fortunately, the CAB isn't operating that way. > > -John Plocher > From rich.teer at rite-group.com Mon Oct 17 10:19:40 2005 From: rich.teer at rite-group.com (Rich Teer) Date: Mon, 17 Oct 2005 10:19:40 -0700 (PDT) Subject: [Fwd: [cab-discuss] CAB Meeting Notes: Wed Oct 12] In-Reply-To: <4350446E.20304@Sun.COM> References: <43503791.7020109@Sun.COM> <4350446E.20304@Sun.COM> Message-ID: On Fri, 14 Oct 2005, Teresa Giacomini wrote: > It does, kinda.... > > There is nothing substantially different from what we presented in > Portland. And, we are talking about process, not implementation. The > proposal we put out is not going to tell us anything about the SCM etc. Gotcha. > Anyone have other thoughts? I don't want our deliverable to be a > dependency for the governance model. In fact, our doc is a proposal and > not the done deal anyway. What if we weren't doing one....the CAB would > still need to have a governance model, right? Right, but I think Roy is interested in knowing some at least some of the details, so he konws from where Sun is coming. > I hope I don't sound too cranky....I'm ready for the weekend! :) Not at all--I hope it was a good one! > ps - I am still learning this transparency thing...should I have asked > this questions on CAB-discuss? Yes; I've CCed cab-discuss on this reply so that Simon and Roy can add their ?0.02 and $0.02 respectively. :-) -- Rich Teer, SCNA, SCSA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich From Bonnie.Corwin at Sun.COM Mon Oct 17 13:25:55 2005 From: Bonnie.Corwin at Sun.COM (Bonnie Corwin) Date: Mon, 17 Oct 2005 14:25:55 -0600 Subject: [cab-discuss] OpenSolaris Charter: draft v2.1 In-Reply-To: <43501336.3060203@sun.com> References: <43501336.3060203@sun.com> Message-ID: <435408D3.50403@Sun.COM> Comments/questions in-line: > The OpenSolaris Charter > (10/14/05 draft v2.1) > > > Introduction > > The OpenSolaris Charter is the title and deed that Sun Microsystems, > Inc. has transferred to the OpenSolaris community. Although Sun > currently sponsors the OpenSolaris project, the OpenSolaris Governing > Board (OGB) is now the body that holds the OpenSolaris Charter, > represents the community, and specifies how decisions are made on the > project through the OpenSolaris Governance. I keep reading this wondering "title and deed to what exactly"? Since the charter is supposed to detail the scope of the OGB (see History section), perhaps: The OpenSolaris Charter defines the principles and high-level organization of the OpenSolaris project. The high-level organization is implemented via the creation of the OpenSolaris Governing Board (OGB). The OGB represents the OpenSolaris community at all times and owns the two primary documents used to govern the community: this Charter and a Governance Document. > > The OpenSolaris Community Mission > > The OpenSolaris Project represents an active community of developers and > users collaborating to improve the OpenSolaris source base on > opensolaris.org. The community's core values -- openness, inclusiveness, > respect, honesty, quality, and independence -- will always be clearly > reflected in how the community and its leaders behave and will help > guide the community as it evolves the OpenSolaris technology. I'm ok with a separate Community and OGB mission - in fact, I think the separation is good. But the flow is funny now. If we include the history in the main document, as opposed to it being an appendix at the end, it seems it should follow the Introduction to provide the background and then move on. > > History of the OpenSolaris Project > > In early 2004, Sun initiated the project to open source the Solaris > operating system. A multi-disciplinary team was formed to consider all > the aspects of the project: licensing, business model, governance, > co-development, source code analysis, source code management, tools, > marketing, and community development. A pilot program was formed in > September of 2004 with 18 non-Sun community members and ran for 9 months > growing to 145 external participants. > > On January 25, 2005, Sun began the formal public phase of opening the > project by initiating the following actions: > > (1) opening the first phase of the opensolaris.org web site, > (2) announcing that OpenSolaris would be released under the CDDL (Common > Development and Distribution License), > (3) releasing the DTrace source under CDDL, and > (4) announcing the intention to form a Community Advisory Board (CAB) of > five members -- two Sun employees, two OpenSolaris Pilot Program > participants elected by the community, and one open source community > member. > > The five CAB members were introduced publicly on April 4, 2005, and > OpenSolaris was officially launched on June 14, 2005. > > When the CAB was formed, Sun requested that the group write two critical > documents: > > (1) a Charter detailing a governing board's scope and > (2) a Governance outlining how the OpenSolaris community would function. > > Sun's intention was to not only open the Solaris source code, but to > also transfer the operations, stewardship, and management of the project > to the OpenSolaris community -- which is now represented by the OGB. > > > OGB Mission Statement > > The OGB provides formal representation and structure for the OpenSolaris > community via the OpenSolaris Charter and the OpenSolaris Governance. The word "Governance" alone bugs me (and maybe only me). "Governance" is an act, a process, a state.....perhaps "the OpenSolaris Governance Document"? > OGB members will always act on behalf of the OpenSolaris community and > honor the community's values in every way possible. > > > OGB Scope > > The scope of the OGB covers anything related to the OpenSolaris project. > In this context, scope means that the OGB has the authority to get > involved in all aspects of the project to ensure that the community is > properly represented. Management of the OpenSolaris project -- including > the source code and its evolution -- is now under the control of the > OpenSolaris community. That community includes the OpenSolaris > developers, system administrators, users, evangelists, and marketers > involved with the project, and their roles are outlined by the > OpenSolaris Governance. The OGB gets involved when there are disputes or > when there are new issues to be devised. Does anyone want parameters about what the scope is not? That's just a question that comes to mind since the first sentence is so broad. 'anything' could potentially mean the OGB could have to manage aspects of the project with which it doesn't want to be involved. To immediately make the meaning clear as it is currently worded, perhaps: The scope of the OGB covers anything related to the OpenSolaris project in that the OGB has the authority to get involved in any aspect of the project to ensure that the community is properly represented. Is the last sentence supposed to say "when there are new issues to be resolved."? > > > OpenSolaris Governing Board Elections > > The OGB consists of seven members who are elected by OpenSolaris > community members with voting privileges as defined in the OpenSolaris > Governance. A quorum of five OGB members will be required to make > significant changes to any of the OpenSolaris governing documents and > those documents will have to be ratified by the community. OGB > candidates are OpenSolaris members in good standing, nominated by the > OpenSolaris membership, and must accept the nomination to be considered. > The voting process is the Single Transferable Vote (STV). Elections are > held once a year on the anniversary of the formation of the first OGB. > There are no term limits. > > Board members will not be assigned specific functions. If a board member > resigns or is otherwise unable to complete his or her term, the next > runner-up in the election will fill that position. There is no > termination from the Board other than by resignation within a term. The > board may, at its discretion and with a quorum of 5 OGB members, decide > to dissolve itself to force a new election. I assume if elections are held once a year that a term is one year? This implies every term is up every year and that there is potentially a completely new board at every cycle. If so, is that wise for continuity? Should terms rotate off in 2s or 3s so that the odds of everyone disappearing at the same time would be so low as to probably not happen? What constitutes 'significant changes' to the governing documents? And what are those documents - I'm assuming just the Charter and the Governance Document? Or are there more? How are changes ratified by the community? The information about changes to the governing documents isn't related to elections - perhaps it should be mentioned in the 'scope' section? > > > Single Transferable Vote > > OGB members are elected by "Single Transferable Vote" as described at: > > http://www.electoral-reform.org.uk/votingsystems/stvi.htm > http://www.cix.co.uk/~rosenstiel/stvrules/index.htm > http://stv.sourceforge.net/ > > To summarize, each member has one vote, but it is cast as an ordered > list of preferred candidates. A later preference is considered only if > an earlier preference has a surplus above the quota required for > election or is excluded because of insufficient support. Under no > circumstances will a later preference count against an earlier > preference. The effect of STV is to balance representation across all > significant groups in the community. > > > Legal Status > > The OGB operates within the scope of this Charter and is not an > independent legal entity. Sun is the lead copyright holder of the > OpenSolaris code, and any legal disputes are resolved by Sun. > > > Community Costs > > At this time, Sun has agreed to fund the OpenSolaris project, which > includes all the infrastructure, the website, the source code management > system and related build and package management tools, marketing and > community development functions, and the administrative costs of the OGB > (including travel expenses for two OGB meetings a year). I agree with Karyn's concern about this section. I don't know exactly how much detail we need, but expectations need to be set. Do we anticipate administrative costs for the OGB beyond travel expenses for two meetings a year (phone conferences, what else?)? Does Sun need to notify the OGB in some timeframe if it decides to stop funding anything it is currently funding? Thanks. Bonnie From Bonnie.Corwin at Sun.COM Tue Oct 25 16:32:53 2005 From: Bonnie.Corwin at Sun.COM (Bonnie Corwin) Date: Tue, 25 Oct 2005 17:32:53 -0600 Subject: [cab-discuss] updated OpenSolaris TOU Message-ID: <435EC0A5.5070501@Sun.COM> Hi - Some of you know that Sun has been working on an updated TOU for the opensolaris.org website. This is partly in response to input after launch and to address sun.com origins that don't apply to opensolaris.org. Attached is an updated draft. Send any questions before next week's Pteam meeting. Thanks. Bonnie -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSolaris_TOU.10.25.05.sxw Type: application/vnd.sun.xml.writer Size: 20601 bytes Desc: not available URL: From Glynn.Foster at Sun.COM Tue Oct 25 18:51:41 2005 From: Glynn.Foster at Sun.COM (Glynn Foster) Date: Wed, 26 Oct 2005 14:51:41 +1300 Subject: [cab-discuss] Re: [program-team] updated OpenSolaris TOU In-Reply-To: <435EC0A5.5070501@Sun.COM> References: <435EC0A5.5070501@Sun.COM> Message-ID: <1130291501.29595.7.camel@localhost> Hi Bonnie, Any chance you could send these documents in plaintext in the future? It becomes very difficult to reply to them inline otherwise, which I think it important if you want people to provide feedback :/ thanks, Glynn On Tue, 2005-10-25 at 17:32 -0600, Bonnie Corwin wrote: > Hi - > > Some of you know that Sun has been working on an updated TOU for the > opensolaris.org website. This is partly in response to input after > launch and to address sun.com origins that don't apply to opensolaris.org. > > Attached is an updated draft. Send any questions before next week's > Pteam meeting. > > Thanks. > > Bonnie > > > > _______________________________________________ > program-team mailing list > program-team at opensolaris.org > http://opensolaris.org/mailman/listinfo/program-team From sommerfeld at sun.com Wed Oct 26 06:52:20 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Wed, 26 Oct 2005 09:52:20 -0400 Subject: [cab-discuss] Re: [program-team] updated OpenSolaris TOU In-Reply-To: <1130291501.29595.7.camel@localhost> References: <435EC0A5.5070501@Sun.COM> <1130291501.29595.7.camel@localhost> Message-ID: <1130334740.17423.97.camel@localhost> On Tue, 2005-10-25 at 21:51, Glynn Foster wrote: > Any chance you could send these documents in plaintext in the future? indeed. if they're going to be put on the web site for people to read, they better be in plaintext rather than sxi or pdf. having reviewed this, i have more than a few comments. 1) three pages of usage terms is a bit much. the bulk of this is really just a notification to the world of site operational policies, distinct from specific conditions on the use of the site. 2) the DMCA take down notice contact info (last page) should perhaps be presented as a separate page on the web site. 3) The notion in the first paragraph that I am becoming a party to the agreement merely by downloading a single public page from the website strikes me as somewhere between presumptuous and offensive, and will annoy people who actually read the fine print. the bulk of this is really just a notification to the world of site operational policies, distinct from specific conditions on the use of the site. (An agreement made while signing up for an account is another matter..) 4) paragraph 2 is the first one which makes any sense whatsoever. 5) paragraph 3 could be construed to impede work on anti-virus/anti-worm software, as a necessary part of that work involves the exchange of (appropriately encapsulated and denatured) worm/virus samples. The "you are prohibited from posting or transmitting to or from ..." the "or from" part I don't get. if someone else's virus-infested PC transmits a worm at a mailing list hosted at the site, and filters don't catch it before it winds up in the archive hosted on the site, why am *I* liable for violating the agreement because the opensolaris.org filters are ineffective? 6) paragraph 9: so, does this mean that sun will not block a client conducting a DDoS on the server without getting lawyers involved first? i don't think you want to imply this... From Bonnie.Corwin at Sun.COM Wed Oct 26 07:59:23 2005 From: Bonnie.Corwin at Sun.COM (Bonnie Corwin) Date: Wed, 26 Oct 2005 08:59:23 -0600 Subject: [cab-discuss] Re: [program-team] updated OpenSolaris TOU In-Reply-To: <1130291501.29595.7.camel@localhost> References: <435EC0A5.5070501@Sun.COM> <1130291501.29595.7.camel@localhost> Message-ID: <435F99CB.9070409@Sun.COM> Sure - text file attached. Bonnie Glynn Foster wrote On 10/25/05 19:51,: > Hi Bonnie, > > Any chance you could send these documents in plaintext in the future? It > becomes very difficult to reply to them inline otherwise, which I think > it important if you want people to provide feedback :/ > > > thanks, > > Glynn > > On Tue, 2005-10-25 at 17:32 -0600, Bonnie Corwin wrote: > >>Hi - >> >>Some of you know that Sun has been working on an updated TOU for the >>opensolaris.org website. This is partly in response to input after >>launch and to address sun.com origins that don't apply to opensolaris.org. >> >>Attached is an updated draft. Send any questions before next week's >>Pteam meeting. >> >>Thanks. >> >>Bonnie >> >> >> >>_______________________________________________ >>program-team mailing list >>program-team at opensolaris.org >>http://opensolaris.org/mailman/listinfo/program-team > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OpenSolaris_TOU.10.25.05.txt URL: From Patrick.Finch at Sun.COM Thu Oct 27 01:40:48 2005 From: Patrick.Finch at Sun.COM (Patrick Finch) Date: Thu, 27 Oct 2005 10:40:48 +0200 Subject: [cab-discuss] Re: [program-team] updated OpenSolaris TOU In-Reply-To: <43608EDC.8050702@sun.com> References: <43608EDC.8050702@sun.com> Message-ID: <43609290.6070702@sun.com> Hi, I'll take it - the last version came from Steven Schulman and I asked if I could work on the style. There is clearly a balance to be struck between providing appropriate legal cover to all parties and not making the document too intimidating. I think that our community members and prospective community members know that a TOU is appropriate for the site and that it is a legal document. However, I also think that explaining motivation in the TOU makes it a lot more readable and assuring. Of course, we need legal to approve expressions of need, aspiration and intention in the TOU, but I do think they can make a document more readable. Bonnie, If I redraft on those lines, can I submit that for Monday? regards Patrick Claire Giordano wrote: > To the OpenSolaris marketing team: > > Is one of you already reviewing and providing input on the TOU? > > I know this is standard legal text and a big improvement over what was > there before. Big thanks to Bonnie for driving this forward. > > I do think, though, that it's impersonal and off-putting, and yet it > doesn't need to be. The lawyers aren't married to a particular "tone > of voice", and just because this is the historical one doesn't mean we > have to stick with the standard tone. > > And while changing the tone for something as boring as a TOU might > seem unnecessary, I think it can help show how much this community > cares about its core values, and about authentic-voice, and about > being different. > > For example, this: > > 13. If you choose to register on this Website, You are responsible for > providing accurate and complete information about yourself during > registration and to updating such information to keep it current. You > accept all risks of unauthorized access to the information that you > provide. Host may, in its sole discretion, terminate the accounts or > access rights of Users who may have provided inaccurate or incomplete > information during registration. > > could likely be written as this: > > 13. If You choose to register on the OpenSolaris.org website (and we > hope you do!) You are responsible for providing accurate and complete > information about yourself. We also ask that You keep your > information current and that You make your profile creative and > interesting. There are risks that the information You provide may be > mis-used or accessed inappropriately by others, since this information > is open to the public, and we need You to knowingly accept these > risks. We may, in our sole discretion, need to terminate accounts or > access rights of any community members who have provided inaccurate or > misleading information during registration. We hope that we don't > have to! > > I'd like the TOU to sound as if a person who actually cares about the > readers and community members wrote it - and not an unkind, selfish > robot. > > Thoughts? > > Claire > > -------- Original Message -------- > Subject: Re: [program-team] updated OpenSolaris TOU > Date: Wed, 26 Oct 2005 08:59:23 -0600 > From: Bonnie Corwin > To: Glynn.Foster at sun.com > CC: program-team at opensolaris.org, cab-discuss at opensolaris.org > References: <435EC0A5.5070501 at Sun.COM> > <1130291501.29595.7.camel at localhost> > > Sure - text file attached. > > Bonnie > > Glynn Foster wrote On 10/25/05 19:51,: > >> Hi Bonnie, >> >> Any chance you could send these documents in plaintext in the future? It >> becomes very difficult to reply to them inline otherwise, which I think >> it important if you want people to provide feedback :/ >> >> >> thanks, >> >> Glynn >> >> On Tue, 2005-10-25 at 17:32 -0600, Bonnie Corwin wrote: >> >>> Hi - >>> >>> Some of you know that Sun has been working on an updated TOU for the >>> opensolaris.org website. This is partly in response to input after >>> launch and to address sun.com origins that don't apply to >>> opensolaris.org. >>> >>> Attached is an updated draft. Send any questions before next week's >>> Pteam meeting. >>> >>> Thanks. >>> >>> Bonnie >>> >>> >>> >>> _______________________________________________ >>> program-team mailing list >>> program-team at opensolaris.org >>> http://opensolaris.org/mailman/listinfo/program-team >> >> >> > >------------------------------------------------------------------------ > > OpenSolaris.org Terms of Use > >BY ACCESSING, BROWSING OR USING THIS WEBSITE, ANY OF ITS SOFTWARE, CONTENT, >SERVICES, OR INFORMATION, YOU ACKNOWLEDGE THAT YOU HAVE READ, UNDERSTOOD >AND AGREE TO BE BOUND BY THESE TERMS OF USE. IF YOU DO NOT AGREE TO ALL OF >THESE TERMS, DO NOT USE THIS WEBSITE. If you are using the Website on >behalf of your employer or another entity, You represent and warrant that >you are authorized to accept these Terms on your employer's or other >entity's behalf, and that your employer or other entity agrees to >indemnify Sun for violations of these Terms of Use. > >1. This OpenSolaris.org Website ("Website") is a service made available by >Sun Microsystems, Inc. ("Host"). All on-line services available via this >Website ("Services"), and all software, documentation, data, information >and other materials provided on or through this Website ("Content") may be >used only under the following terms and conditions ("Terms of Use") and any >applicable licenses. > >2. Host and the users of this Website ("Users") do not want to receive >confidential information from you through this Website. ANY INFORMATION >OR MATERIAL YOU SUBMIT TO THIS WEBSITE WILL BE DEEMED NOT TO BE >CONFIDENTIAL. You are responsible for the Content that you submit, and you, >not Host, have full responsibility for that Content, including its legality, >reliability, appropriateness, originality, and related patent and copyright >matters. > >3. You are prohibited from posting or transmitting to or from this Website >any unlawful, threatening, libelous, defamatory, obscene, pornographic, >or profane material, any software virus, worm or other material of a >disruptive or destructive nature, or any other material that could give >rise to any civil or criminal liability under the law. You are further >prohibited from using this Website to: (a) transmit spam, bulk or >unsolicited communications; (b) pretend to be Host or someone else, or >spoof Host's or someone else's identity; (c) forge headers or otherwise >manipulate identifiers (including URLs) in order to disguise the origin of >any Service or Content transmitted via this Website; (d) misrepresent your >affiliation with a person or entity; (e) disrupt the normal flow of >dialogue or otherwise act in a manner that negatively affects Users' >ability to use this Website; (f) engage in activities that would violate >any applicable local, state, national or international law, or any >regulations having the force of law, including but not limited to >attempting to compromise the security of any networked account or site, >stalking, or making threats of harm; or (g) collect or store personal >data about other Users unless specifically authorized by such Users. > >4. The Website may contain links to third-party websites or resources. >Host and the Users make no representations whatsoever about any other >website or external resources that you may access through this Website or >through a link from this Website. When you access another website or >external resource, even one that may contain this Website's name or mark, >you acknowledge and agree that it is independent and that Host is not >responsible or liable for: (a) the availability or accuracy of such >websites or resources; or (b) the content, products, or services on or >available from such websites or resources. Links to such websites or >resources do not mean that the Users or Host endorse or accept any >responsibility for the content on, or the use of, such websites or >external resources. You acknowledge sole responsibility for and assume >all risk arising from your use of any such websites or resources. > >5. Host may run advertisements and promotions from third parties on this >Website. Any action you may take based upon such advertisements or >promotions of a third party, and any dealings you may have with such >third party are solely between you and that third party. Host is not >responsible or liable for any loss or damage of any sort incurred as to >result of any such actions or dealings or as a result of the presence of >any non-Sun advertiser on this Website. > >6. TO THE FULL EXTENT PERMITTED BY LAW, HOST IS NOT LIABLE TO YOU OR ANY >OTHER INDIVIDUAL OR ENTITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, PUNITIVE, >SPECIAL OR CONSEQUENTIAL DAMAGES RELATED TO OR ARISING OUT OF ANY USE OF, >ACCESS TO, OR INABILITY TO ACCESS THIS WEBSITE, CONTENT, SERVICES, OR OF >ANY OTHER LINKED WEBSITE OR EXTERNAL RESOURCE INCLUDING, WITHOUT >LIMITATION, ANY LOST PROFITS, LOST SALES, LOST REVENUE, LOSS OF GOODWILL, >BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR OTHER DATA EVEN IF SUN IS >EXPRESSLY ADVISED OR AWARE OF THE POSSIBILITY OF SUCH DAMAGES OR LOSSES. >YOU ASSUME ALL RISK FOR ANY DAMAGE TO YOUR COMPUTER SYSTEM OR LOSS OF >DATA THAT RESULTS FROM OBTAINING ANY CONTENT FROM THE WEBSITE, INCLUDING >ANY DAMAGES RESULTING FROM COMPUTER VIRUSES, WORMS, OR OTHER ITEMS OF A >DESTRUCTIVE NATURE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR >LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, SO THE >ABOVE LIMITATION MAY NOT APPLY TO YOU. > >7. ALL SERVICES AND CONTENT ARE PROVIDED BY HOST ON AN "AS IS", "AS >AVAILABLE", AND "WITH ALL FAULTS" BASIS ONLY. YOU ASSUME ALL RISK OF >LOSS OR OTHER HARM FOR THE USE THEREOF. HOST PROVIDES NO REPRESENTATIONS, >CONDITIONS AND/OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, WITHOUT >LIMITATION, THE IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE, >MERCHANTABILITY AND NONINFRINGEMENT. HOST MAKES NO WARRANTY OR >REPRESENTATION THAT: (A) THIS WEBSITE WILL BE UNINTERRUPTED, TIMELY, >SECURE, OR ERROR-FREE; (B) CONTENT, SERVICES, OR RESULTS THAT MAY BE >OBTAINED FROM THE USE OF THIS WEBSITE WILL BE ACCURATE OR RELIABLE; >(C) THE QUALITY OF ANY PRODUCTS, SERVICES, CONTENT, INFORMATION, OR OTHER >MATERIAL PURCHASED OR OBTAINED FROM THIS WEBSITE WILL MEET YOUR >EXPECTATIONS OR REQUIREMENTS; OR (D) ANY ERRORS IN THIS WEBSITE, CONTENT >OR SERVICES WILL BE CORRECTED. > >8. Host reserves the right to investigate complaints or reported >violations of these Terms of Use, and/or applicable licenses and copyright >information on the Website and to take any action Host deems appropriate >including, without limitation, reporting and providing information of any >suspected unlawful activity to law enforcement officials, regulators, or >other third parties, including disclosing any information necessary or >appropriate to such persons or entities relating to user profiles, e-mail >addresses, usage history, posted materials, IP addresses, and traffic >information. > >9. Host reserves the right to seek all remedies available at law and in >equity for violations of these Terms of Use, including, but not limited >to, the right to block access from a particular Internet address to this >Website. > >10. This Website may contain other proprietary notices, licenses and >copyright information, the terms of which must be observed and followed >by you. In the event of any conflict between the license(s) applicable >to Content or Services and the Terms of Use, the applicable license(s) >prevail. Except as otherwise expressly stated, by providing the Content >or Services, Host does not grant any licenses to any copyrights, patents >or any other intellectual property rights. > >11. The Content provided on this Website is provided under the terms and >conditions of the applicable license(s) on the Website. Any Content >provided by you is made available to Users and Host under the terms of >the license(s) applicable to contributing such Content to the Website. >For all Content, including, without limitation, patent, copyright, and >other intellectual property rights in such Content, owned or licensable >by you at any time without payment, ideas, concepts, know-how and >techniques, uploaded, submitted or otherwise made available by you on the >Website or to the Users and/or Host (collectively "Material"), you grant >(or warrant that the owner of such rights has expressly granted) Host a >worldwide, unrestricted, royalty-free, fully paid up, irrevocable, >perpetual, non- exclusive license to use, make, reproduce, import, >compile, prepare derivative works of, publicly display, publicly perform, >transmit, sell, distribute, sublicense, demonstrate, market, disclose, >have made, offer for sale, lease, transfer or otherwise exploit such >Materials, and/or derivative works thereof, and authorize third parties >to do any, some or all of the foregoing including, but not limited to, >sublicensing others to do any, some or all of the foregoing indefinitely. >You represent that you are legally entitled to grant the rights and >privileges conveyed by this section and warrant that your Material, to >the best of your knowledge, does not violate any other party's patents, >copyrights, trademarks or other intellectual property rights. > >12. You acknowledge that Host: (i) does not pre-screen Content; (ii) has >discretion to determine whether to post or not post Content; and (iii) can >delete, cease providing, or modify the Content at any time for any reason. >The Content on this Website may contain technical inaccuracies or >typographical errors. Host may also improve or change the Content at any >time without notice. Host reserves the right, at any time, with or >without cause and without notice, to modify, suspend or terminate in whole >or in part: (i) the Services, (ii) your use or access to the Services, or >(iii) both. Host is not liable to you or any third party for any >modification or deletion of Content, for any posting refusal to post >Content, or any modification, suspension or termination of Services. > >13. If you choose to register on this Website, You are responsible for >providing accurate and complete information about yourself during >registration and to updating such information to keep it current. You >accept all risks of unauthorized access to the information that you >provide. Host may, in its sole discretion, terminate the accounts or >access rights of Users who may have provided inaccurate or incomplete >information during registration. > >14. Host is committed to respecting the intellectual property rights of >others, and we ask our Users to do the same. Host may, in its sole >discretion, terminate the accounts or access rights of Users who may be >infringing or may otherwise be violating the intellectual property rights >of others. If you believe that your work has been copied on this Website >in a way that constitues infringement, please contact the copyright agent >as described in the copyright policy set forth in detail elsewhere on the >Website. The Website, Services, and Content are protected by copyright, >trademark, and other laws of both the United States and foreign countries. >Except as expressly permitted in these Terms of Use and any applicable >license, you may not reproduce, modify, or prepare derivative works based >upon, distribute, sell, transfer, publicly display, publicly perform, >transmit, or otherwise use the Website, Services, or Content. You may >not copy or modify the HTML code used to generate web pages on the >Website. > >15. California law and controlling U.S. Federal law govern any action >relating to these Terms of Use without regard to any jurisdiction's >choice law rules. You agree to submit all such disputes to the personal >and exclusive jurisdiction of the state and federal courts located within >the county of Santa Clara, California USA. > >16. Host may amend these Terms of Use at any time by posting the amended >terms on this Website. By continuing to access or use the Website, >Services or Content after Host makes any such revision, you agree to be >bound by the revised Terms of Use. > >17. "Host Trademarks" means all names, marks, brands, logos, designs, >trade dress, slogans and other designations Host uses in connection with >its products and services. You agree to comply with the Trademark and >Logo Usage Requirements located at http://www.sun.com/policies/trademarks. >You may not remove or alter any Host Trademarks, or co-brand your own >products or material with Host Trademarks, without Host's prior written >consent. You acknowledge Host's rights in Host Trademarks and agree that >any use of Host Trademarks by you shall inure to Host's sole benefit. >You agree not to incorporate any Host Trademarks into your trademarks, >service marks, company names, Internet addresses, domain names, or any >other similar designations, for use on or in connection with computer or >Internet-related products, services or technologies. > >18. You consent to the collection, processing and storage by Host of your >personal information in accordance with the terms of Host's Privacy >Policy, which is available at http://www.sun.com/privacy. You agree to >comply with all applicable laws and regulations, and the terms of that >privacy policy, with respect to any access, use and/or submission by you >of any personal information in connection with this Website. > >Notwithstanding anything to the contrary, if you choose to participate in >an open source or community source process on this Website, whether by >contributing code, participating in mailing lists or sending e-mails, your >participation is public and your privacy cannot be protected to the extent >that you provide personal information such as your e-mail address. To the >extent that you contribute code, information, articles or other material >to this Website containing personal information, Host cannot protect the >privacy of such personal information and such material may be provided to >others under the Terms of Use and applicable licenses. > >19. The Website may contain forward-looking statements within the meaning >of the Private Securities Litigation Reform Act of 1995. Such forward- >looking statements may include statements regarding market expectations >and opportunities, expectations about financials, research and development >and strategies, statements concerning Host's roadmaps, market share growth, >and product and service development and introduction, and our continuous >evaluation of the competitiveness of our product and service offerings. >These forward-looking statements are just predictions and involve risks >and uncertainties. Actual results may differ materially from results >discussed in the forward-looking statements. Factors that may cause such >a difference include risks related to adverse changes in general economic >conditions, failure to reduce costs, lack of success in technical >advancements, the timely development, production and acceptance of new >products and services, and Sun's ability to compete in a highly >competitive and rapidly changing marketplace. For a detailed listing of >the potential factors affecting Host's business and these forward-looking >statements, please refer to Host's periodic reports on Forms 10-Q and >10-K that are filed with the Securities and Exchange Commission. > >20. Any express waiver or failure to exercise promptly any right under >the Terms of Use will not create a continuing waiver or any expectation >of non-enforcement. If any provision of the Terms of Use is held invalid >by any law or regulation of any government, or by any court or arbitrator, >such provision will be replaced with a new provision that accomplishes the >original business purpose, and the other provisions of the Terms of Use >will remain in full force and effect. > >21. In addition to the Terms of Use and unless otherwise noted, the >standard Host terms and conditions of sale in your jurisdiction govern >purchases you make through the Website, unless you have in effect a >separate valid written purchase or license agreement with Host for the >products or services purchased, in which case that separate agreement >governs, and in cases of conflict, prevails. > >Copyright Policy > >Host is committed to respecting others' intellectual property rights, and >we ask that users of this Website do the same. Host may, in its sole >discretion and in appropriate circumstances, terminate the accounts or >access rights of users who violate others' intellectual property rights. > >Pursuant to 17 United States Code 512(c)(2) (Digital Millennium Copyright >Act of 1998), Host's designated agent for notice of alleged copyright >infringement appearing on the Website is: > >Copyright Counsel, Sun Microsystems Inc. >4150 Network Circle, Santa Clara, CA 95054 >Ph: 650-786-3142 >Fax: 650-786-2325 >Email: copyrights at sun.com > >Filing a notice of infringement with Host requires compliance with the >requirements specified in Title II of the Digital Millennium Copyright Act >of 1998. The text of this statute can be found at the U.S. Copyright >Office website, www.copyright.gov. If you believe that your work has been >copied in a way that constitutes copyright infringement on this Website, >please deliver the following information to Host's Copyright Agent: > >1. An electronic or physical signature of the person authorized to act on > behalf of the copyright owner; >2. A description of the copyrighted work that you claim has been infringed; >3. A description of the material that you claim is infringing; >4. A description of the location on this Website of the material that you > claim is infringing; >5. Your address, telephone number and e-mail address so that we can > contact you; >6. A statement by you that you have a good faith belief that the disputed > use is not authorized by the copyright owner, its agent or the law; and >7. A statement by you, made under penalty of perjury, that the information > in your notice to Host is accurate and that you are the copyright owner > or authorized to act on behalf of the copyright owner. > > > >------------------------------------------------------------------------ > >_______________________________________________ >program-team mailing list >program-team at opensolaris.org >http://opensolaris.org/mailman/listinfo/program-team > > > From Karyn.Ritter at Sun.COM Mon Oct 31 20:24:03 2005 From: Karyn.Ritter at Sun.COM (Karyn Ritter) Date: Mon, 31 Oct 2005 20:24:03 -0800 Subject: [cab-discuss] OGB Charter v2.3 Message-ID: <4366EDE3.5040502@sun.com> Jim is out of the office, so I've agreed to send out the updated Charter along with the details about what changed and why. Stephen Harpster, Stephen Hahn, Jim Grisanzio, Steven Schulman (legal), and Karyn Ritter reviewed the final version of the OGB Charter submitted by the CAB. Jim made changes based on the feedback, and those changes are reflected in this version of the Charter. Aside from cosmetic changes, the bulk of the edits were to move sections of the Charter to the Governance document: Elections, SVT, Legal Status, and Community Costs. We felt these sections needed to be more fully explored, and that the appropriate place to do it was in the Governance documents. Ideally, wording from these sections in the Charter should be used as the basis for the Governance documents. Here are some of the specific issues within the Charter that should be considered/resolved within the Governance documents: * Need a mechanism for the OGB to request funds from Sun now that the budget and community costs have been removed from the Charter. * OGB election procedures are to be moved to the Governance. Also, we need a better explanation of the process, and that process needs to include requirements for participation and procedures to remove board members if necessary. * Process for changing the Charter and/or Governance in the future. * Process for the OGB to increase/decrease its scope via the Charter. * OGB membership: Level of Sun participation/membership. Staggered terms to foster consistency? This is the version of the OGB Charter that Sun approves, but we are happy to review and approve a later version modified with CAB and community input. Please let me know if you have any problems or questions with this. The latest version of the Charter follows. Thanks, Karyn ~~~~~~~~~~~~ The OpenSolaris Charter (10/28/05 draft v2.3) Introduction The OpenSolaris Charter defines the high level principles for the OpenSolaris project and creates the OpenSolaris Governing Board (OGB). The OGB focuses and directs the energies of the OpenSolaris community. History of the OpenSolaris Project In early 2004, Sun initiated the project to open source the Solaris operating system. A multi-disciplinary team was formed to consider all the aspects of the project: licensing, business model, governance, co-development, source code analysis, source code management, tools, marketing, and community development. A pilot program was formed in September of 2004 and ran for 9 months. On January 25, 2005, Sun began the public phase of the project by initiating the following actions: (1) opening the first phase of the opensolaris.org web site, (2) announcing that OpenSolaris would be released under the Common Development and Distribution License (CDDL), (3) releasing the DTrace source code under CDDL, and (4) announcing the intention to form a Community Advisory Board (CAB) made up of five members -- two Sun employees, two OpenSolaris Pilot Program participants elected by the pilot community, and one open source community member. The five CAB members were introduced publicly on April 4, 2005, and OpenSolaris was officially launched on June 14, 2005. When the CAB was formed, Sun requested that the group write two documents: a Charter detailing a governing board's scope and Governance documents outlining how the OpenSolaris community would function. By enfranchising a community governing board, Sun's intention is to facilitate the growth of the OpenSolaris project and embrace the efforts of the OpenSolaris community. The OpenSolaris Community Values and Mission The OpenSolaris Project represents a community whose members collaborate openly to improve the OpenSolaris source code. The community's core values -- openness, inclusiveness, respect, honesty, quality, independence -- will guide the community as it evolves the OpenSolaris technology. The OGB provides guidance and structure for the community. OGB members will honor the community's values in its activities and decisions. OpenSolaris Governing Board Scope Management of the OpenSolaris project -- including the source code and its evolution -- is under the control of the OpenSolaris community as represented by the OGB. The OGB consists of members who are elected by the OpenSolaris community, which includes the OpenSolaris developers, system administrators, users, evangelists, and marketers involved with the project and whose membership roles are outlined by the Governance documents. The OGB has the authority to get involved in all aspects of the OpenSolaris project to ensure that the community is properly represented. - End - From benr at cuddletech.com Mon Oct 31 23:49:48 2005 From: benr at cuddletech.com (Ben Rockwood) Date: Mon, 31 Oct 2005 23:49:48 -0800 Subject: [cab-discuss] OGB Charter v2.3 In-Reply-To: <4366EDE3.5040502@sun.com> References: <4366EDE3.5040502@sun.com> Message-ID: <43671E1C.8080301@cuddletech.com> I hesitate to even send this comment, but I'm compelled. Is this it? As sent, the line-for-line breakdown is as follows (not counting blank lines): Introduction: 3 lines History: 24 Values: 5 OGB Scope: 9 I can't help but compare this to shaving a poodle. You shave and shave until you realize there is nothing left. What is left seems like fluff to me. I'm sorry, but this document doesn't say anything at all. It breaks down like this: A) There was a pilot, it was great. B) We believe in being nice and getting along C) The OGB will stay out of the way until they want to "get involved" in something. Frankly I'm unsure why "Sun approves". What is there to approve? I'm very very sorry to be so critical, but this charter isn't the solution. I welcome the opinion of anyone who thinks differently and can change my mind. benr. Karyn Ritter wrote: > Jim is out of the office, so I've agreed to send out the updated > Charter along with the details about what changed and why. > > Stephen Harpster, Stephen Hahn, Jim Grisanzio, Steven Schulman > (legal), and Karyn Ritter reviewed the final version of the OGB > Charter submitted by the CAB. Jim made changes based on the feedback, > and those changes are reflected in this version of the Charter. > > Aside from cosmetic changes, the bulk of the edits were to move > sections of the Charter to the Governance document: Elections, SVT, > Legal Status, and Community Costs. We felt these sections needed to be > more fully explored, and that the appropriate place to do it was in > the Governance documents. Ideally, wording from these sections in the > Charter should be used as the basis for the Governance documents. > > Here are some of the specific issues within the Charter that should be > considered/resolved within the Governance documents: > > * Need a mechanism for the OGB to request funds from Sun now that > the budget and community costs have been removed from the Charter. > * OGB election procedures are to be moved to the Governance. Also, > we need a better explanation of the process, and that process > needs to include requirements for participation and procedures to > remove board members if necessary. > * Process for changing the Charter and/or Governance in the future. > * Process for the OGB to increase/decrease its scope via the > Charter. > * OGB membership: Level of Sun participation/membership. Staggered > terms to foster consistency? > > This is the version of the OGB Charter that Sun approves, but we are > happy to review and approve a later version modified with CAB and > community input. > > Please let me know if you have any problems or questions with this. > The latest version of the Charter follows. > > Thanks, > > Karyn > > ~~~~~~~~~~~~ > > The OpenSolaris Charter > > (10/28/05 draft v2.3) > > Introduction > > The OpenSolaris Charter defines the high level principles for the > OpenSolaris project and creates the OpenSolaris Governing Board (OGB). > The OGB focuses and directs the energies of the OpenSolaris community. > > History of the OpenSolaris Project > > In early 2004, Sun initiated the project to open source the Solaris > operating system. A multi-disciplinary team was formed to consider all > the aspects of the project: licensing, business model, governance, > co-development, source code analysis, source code management, tools, > marketing, and community development. A pilot program was formed in > September of 2004 and ran for 9 months. > > On January 25, 2005, Sun began the public phase of the project by > initiating the following actions: > > (1) opening the first phase of the opensolaris.org web site, > (2) announcing that OpenSolaris would be released under the Common > Development and Distribution License (CDDL), > (3) releasing the DTrace source code under CDDL, and > (4) announcing the intention to form a Community Advisory Board (CAB) > made up of five members -- two Sun employees, two OpenSolaris Pilot > Program participants elected by the pilot community, and one open > source community member. > > The five CAB members were introduced publicly on April 4, 2005, and > OpenSolaris was officially launched on June 14, 2005. When the CAB was > formed, Sun requested that the group write two documents: a Charter > detailing a governing board's scope and Governance documents outlining > how the OpenSolaris community would function. By enfranchising a > community governing board, Sun's intention is to facilitate the growth > of the OpenSolaris project and embrace the efforts of the OpenSolaris > community. > > The OpenSolaris Community Values and Mission > > The OpenSolaris Project represents a community whose members collaborate > openly to improve the OpenSolaris source code. The community's core > values -- openness, inclusiveness, respect, honesty, quality, > independence -- will guide the community as it evolves the OpenSolaris > technology. The OGB provides guidance and structure for the > community. OGB members will honor the community's values in its > activities and decisions. > > OpenSolaris Governing Board Scope > > Management of the OpenSolaris project -- including the source code and > its evolution -- is under the control of the OpenSolaris community as > represented by the OGB. The OGB consists of members who are > elected by > the OpenSolaris community, which includes the OpenSolaris developers, > system administrators, users, evangelists, and marketers involved with > the project and whose membership roles are outlined by the Governance > documents. The OGB has the authority to get involved in all aspects of > the OpenSolaris project to ensure that the community is properly > represented. > > > - End - > _______________________________________________ > cab-discuss mailing list > cab-discuss at opensolaris.org From claire.giordano at sun.com Thu Oct 27 01:25:00 2005 From: claire.giordano at sun.com (Claire Giordano) Date: Thu, 27 Oct 2005 01:25:00 -0700 Subject: [cab-discuss] Re: [program-team] updated OpenSolaris TOU Message-ID: <43608EDC.8050702@sun.com> To the OpenSolaris marketing team: Is one of you already reviewing and providing input on the TOU? I know this is standard legal text and a big improvement over what was there before. Big thanks to Bonnie for driving this forward. I do think, though, that it's impersonal and off-putting, and yet it doesn't need to be. The lawyers aren't married to a particular "tone of voice", and just because this is the historical one doesn't mean we have to stick with the standard tone. And while changing the tone for something as boring as a TOU might seem unnecessary, I think it can help show how much this community cares about its core values, and about authentic-voice, and about being different. For example, this: 13. If you choose to register on this Website, You are responsible for providing accurate and complete information about yourself during registration and to updating such information to keep it current. You accept all risks of unauthorized access to the information that you provide. Host may, in its sole discretion, terminate the accounts or access rights of Users who may have provided inaccurate or incomplete information during registration. could likely be written as this: 13. If You choose to register on the OpenSolaris.org website (and we hope you do!) You are responsible for providing accurate and complete information about yourself. We also ask that You keep your information current and that You make your profile creative and interesting. There are risks that the information You provide may be mis-used or accessed inappropriately by others, since this information is open to the public, and we need You to knowingly accept these risks. We may, in our sole discretion, need to terminate accounts or access rights of any community members who have provided inaccurate or misleading information during registration. We hope that we don't have to! I'd like the TOU to sound as if a person who actually cares about the readers and community members wrote it - and not an unkind, selfish robot. Thoughts? Claire -------- Original Message -------- Subject: Re: [program-team] updated OpenSolaris TOU Date: Wed, 26 Oct 2005 08:59:23 -0600 From: Bonnie Corwin To: Glynn.Foster at sun.com CC: program-team at opensolaris.org, cab-discuss at opensolaris.org References: <435EC0A5.5070501 at Sun.COM> <1130291501.29595.7.camel at localhost> Sure - text file attached. Bonnie Glynn Foster wrote On 10/25/05 19:51,: > Hi Bonnie, > > Any chance you could send these documents in plaintext in the future? It > becomes very difficult to reply to them inline otherwise, which I think > it important if you want people to provide feedback :/ > > > thanks, > > Glynn > > On Tue, 2005-10-25 at 17:32 -0600, Bonnie Corwin wrote: > >>Hi - >> >>Some of you know that Sun has been working on an updated TOU for the >>opensolaris.org website. This is partly in response to input after >>launch and to address sun.com origins that don't apply to opensolaris.org. >> >>Attached is an updated draft. Send any questions before next week's >>Pteam meeting. >> >>Thanks. >> >>Bonnie >> >> >> >>_______________________________________________ >>program-team mailing list >>program-team at opensolaris.org >>http://opensolaris.org/mailman/listinfo/program-team > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: OpenSolaris_TOU.10.25.05.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file:///tmp/nsmail-2.asc URL: