Shawn, It looks like you plan to have representation from Belenix/Kindiana/Indiana and Schillix teams. Have you reached out to the PowerPC, Nexenta and MartUX teams yet? I don't see any of their team members listed in the core contributor list, and their input into this proposal / process would strengthen it as an accurate representation of the community's needs and goals. (They are not mentioned in your proposal, but are OpenSolaris distros based on the existing ARC approved O/N source tree.).
John's notes about forking O/N concern me. It "seems" to me to be a bypass of the ARC process, creating a separate O/N "fork" for Indiana based distros. Please clarify: is the long term goal of this "trunk" to introduce a "streamlined" patch integration process that will eventually replace the ARC process for O/N integration? If so, this merits further discussion. (Possibly as a project in an existing community, and possibly under a separate website, that does not use the Sun trademark OpenSolaris, and certainly with the input of other distro teams. IE: Nexenta, and MartUX.) It seems that we are risking the inadvertent introduction of a potentially unsustainable process; keeping the ARC approved branch in bidirectional sync with the "Indiana-distro" branch would introduce a new level of overhead that may be difficult and/or costly to sustain. If you have a technical solution for feeding changes back and forth between the ARC source tree and the Indiana-distro source tree, please include this as part of your proposal. (I refrain from the phrase "distro source tree", because it currently begs the question, "Which distro source tree?", and for now it seems that the only distro that will be using this source tree is "Indiana".) Could you describe the operational process that would facilitate this continuous integration, and explain the benefits of this change to the OpenSolaris community at large? Some thoughts/questions: 1) Currently Indiana is a project. Indiana also has a mailing list, and has spawned additional mailing lists. (pkg-discuss being one that I can recall). It seems that Indiana has not had an issue obtaining the resources it needs under the current CG structure. 2) What resources beyond the scope of a project does Indiana need? 3) What is wrong with the scope of the current CGs that are sponsoring Indiana? 4) I understand that "request sponsor" has issues currently. Might further opening up the ARC/request-sponsor process make more sense than building a parallel process? (Forgive me if I have used the wrong terminology, or am misunderstanding your proposal.) 5) You comment that, "the tools necessary to build a distribution are quickly reaching maturity." The "tools necessary to build a distro" have been in use by the various distros for quite some time. Are the tools you are referring to Indiana specific tools? If so, is using these tools a prerequisite for membership in the proposed distro CG? Is so, what do you propose for distros that use different tool-chains? (e.g. - Nexenta, and MartUX). 6) You also state one of the reasons for this CG is: "...to avoid some of the past problems that have arisen." Could you please elaborate on these issues? I am not sure everyone is aware of these issues. (I certainly am not aware of what you are referring to.) 7) I am at a loss with regard to the following point. "Additionally, the Distribution Community Group will help establish a clear chain of responsibility by ensuring that distribution projects are directly responsible to a particular Community Group. This allows a first line of arbitration, and active guidance that distribution projects need." Could you please clarify which distribution projects have expressed a "need" for "active guidance", that you state is lacking? At this point, it seems that this proposal is heavily influenced by the members and the needs of a single distribution family. (The list of core contributors you are proposing seems to be taken almost entirely from the "Project leaders" page for the Indiana project, http://opensolaris.org/os/project/indiana/leaders/) Without adequate and equal representation from all of the other distro communities, particularly Nexenta, I have to vote -1 for the current proposal. Cheers, Brian On Jan 20, 2008 3:53 PM, Shawn Walker <swalker at opensolaris.org> wrote: > On Jan 16, 2008 1:12 PM, Keith M Wesolowski <keith.wesolowski at sun.com> > wrote: > > Mr. Walker, please post a copy of your proposal here. We need a > > single consistent text for people to review and comment on. You could > > always edit your blog entry... > > Based on comments received so far, I have completed a new version of > this proposal. That nature of the proposal has not changed, although > it should be much clearer what is being proposed now. > > Summary > ========== > The OpenSolaris community needs a new Community Group to facilitate > collaboration, design, and development of OpenSolaris-based > distributions. Because of new tools that are already available to the > community, but are rapidly reaching maturity, it is probable that > there will be a large number of community-based distributions being > created soon. In addition, the current set of Community Groups > available to sponsor projects are not properly scoped or otherwise > suitable for the nature and goals of distribution projects. As such, > the creation of a new Community Group is needed. > > Scope > ========== > The proposed Distribution Community Group shall be the group to which > the OGB delegates responsibility for encouraging the sustained growth > and success of OpenSolaris-based distribution projects. Distributions > that have previously been sponsored by another Community Group may > remain with that group. However, it is hoped that all such projects > will approach the contributors of this new community to seek > reassignment (sponsorship), or that if necessary, they be reassigned. > > The Distribution Community Group should be the central place for > discussions and decisions regarding OpenSolaris-based distributions > and their impact upon the OpenSolaris community. To support this, it > is proposed that the OGB will allow the group to act as the initial > arbiter in dispute resolution amongst distributions and related > projects. > > Some examples of dispute resolution might include: acting as an > arbiter between distribution project leaders when disagreement between > them arises, ensuring that any relevant policies and guidelines > established by the constitution or authorised governing body are > followed, and encouraging reconciliation when there are disputes. > > The Distribution Community Group will actively work to ensure that > there is a healthy relationship between its sponsored projects and the > rest of the community. It will accomplish this by doing things such > as: ensuring that feedback from the group's sponsored projects is > provided to the related Community Groups and projects, encouraging the > further development and creation of tools related to the development > of distribution projects, and ensuring that projects coordinate their > releases with related Community Groups (such as the Advocacy Community > Group). > > The Distribution Community Group will also work to establish unified > processes and resources to assist distribution projects in > contributing to the sustained growth and success of our community. The > usage of a common set of resources will help keep our community's > efforts from becoming fragmented. Promoting the use of these unified > resources and processes (such as a reference technology platform) will > allow individuals to be free to innovate in many areas of OpenSolaris > technology instead of reinventing the basic tools and processes that > every distribution project needs to operate. > > Initial Projects > ========== > The following are a series of projects that the Community Group should > begin once it is formed. > > With the acceptance of Project Indiana, and the acceptance of the > initial set of core contributors, Project Indiana should be reassigned > to the new Community Group or seek re-sponsorship. > > As part of encouraging the sustained growth and success of > community-based distributions, it is highly desirable that a new > project oriented towards ON Community Group developers be created. > This new project would maintain a branch of the main ON tree that > integrates patches from community developers on a rapid basis as they > are approved for inclusion. It will build the resulting source tree on > frequent basis (to be determined, with the initial goal being weekly). > This will allow community developers to quickly see and test the > results of their contributions while encouraging innovation and > providing an easy method for developers to obtain feedback from other > community members. > > The aforementioned project, will also serve as a testbed for > developing unified processes and tool usage (such as the distribution > constructor) while ensuring individuals are free to innovate. The > resulting distribution, by using these tools and processes, will be a > valuable asset. > > Rationale > ========== > There are many reasons a Distribution Community Group is needed. One > of them is that past events have shown that none of the existing > community groups are wholly suitable for the community-wide impact > that distributions can have within the OpenSolaris community. In > addition, none of the existing Community Groups are properly scoped > for the kind of decisions that need to made to by a knowledgeable, > focused group of individuals whose primary interest relates to the > production of distributions. > > Additionally, the Distribution Community Group will help establish a > clear chain of responsibility by ensuring that distribution projects > are directly responsible to a particular Community Group. This allows > a first line of arbitration, and active guidance that distribution > projects need. > > Finally, the tools necessary to build a distribution are quickly > reaching maturity, and the Community Group will encourage individuals > creating or maintaining distributions to participate directly in the > OpenSolaris community to avoid some of the past problems that have > arisen. > > Proposal > ========== > The core of this proposal is to: > > * Create a Distribution Community Group > * That existing distribution projects be encouraged to seek > re-sponsorship or be reassigned to to this new community > * That the following individuals be considered for the initial set > of core contributors with their acceptance: > o Shawn Walker (id: swalker) (proposed facilitator) > o Ken Mays (id: kmays) > o Eric Boutilier (id: ericb) > o Danek Duvall (id: dduvall) > o Dennis Clarke (id: dclarke) > o David Comay (id: comay) > o Sara Dornsife (id: sarad) > o Glynn Foster (id: gman) > o Moinak Ghosh (id: moinakg) > o Stephen Hahn (id: sch) > o Dave Miner (id: dminer) > o Ian Murdock (id: imurdock) > o John Plocher (id: plocher) > o Joerg Schilling (id: joerg) > o Bart Smaalders (id: barts) > > > I would ask the OGB consider this proposal two weeks from January 16th, 2008. > > Thank you for your attention to this matter. > > [Proposal Version 3 - Updated Jan 19th, 2008 12:35am CDT] > > -- > Shawn Walker, Software and Systems Analyst > http://binarycrusader.blogspot.com/ > > "To err is human -- and to blame it on a computer is even more so." - > Robert Orben > _______________________________________________ > > ogb-discuss mailing list > ogb-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ogb-discuss > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/
