On Jan 21, 2008 9:54 PM, S h i v <shivakumar.gn at gmail.com> wrote: > A request to the OGB: > I believe this proposal is quite broad in scope and of direct > relevance to the entire OS.o community. Hence I request the OGB to > ensure that the core-contributors of the existing CGs (and/or > contributors) have had an opportunity to respond to the proposal. > I am not sure if all the core-contributors actively go through all > proposals sent to the OGB list.
There is a 14-day comment period in which all individuals are free to respond if interested. > My comments below: > > On Jan 21, 2008 2:23 AM, Shawn Walker <swalker at opensolaris.org> wrote: > > > > 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. > > In principle this looks fine. This would essentially make this a CG > that can make far reaching decisions. > > Given the current structuring of OS.o and the past precedences, I see > a problem here. > During the Indiana controversy, some of the advocacy group members > claimed exclusive "product management" right & expertise. Creation of > a Distro Community essentially puts this in black & white form under a > different CG head. Not really. This proposal in no way takes any of the powers, responsibilities that have already been delegated to other communities away. I am not proposing any such item. > > > > 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. > > > [snip] > > > > 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.[snip] > > > > An observation here: The above scope along with this CG(projects > under) maintaining their own ON tree(as mentioned below), defining the > processes, developing tools, etc makes this CG a meta-CG bringing into > its ambit many of the existing CGs (if not on paper definitely in the > nature of influence). There appears to be confusion about the proposal. The only thing the proposal is actually proposing is in the "Proposal" section. The proposal is *not* suggesting that the Distribution Community Group would somehow maintain an official fork or branch of the ON tree. In addition, the initial projects are just that; suggestions for initial projects. A Community Group is a place where projects live; the projects itself do not necessarily represent the group in its entirety. > > 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. > > > > There is no justification for maintaining a separate branch of the ON > tree. The backbone of the OS.o is the ON consolidation, forking it > essentially breaks the very idea of *unified processes* that this > proposal talks about. Actually there is. See Nexenta, SchilliX, Belenix. Each of them had completely reasonable justification for maintaining their own code for functionality not available in the main ON tree. They still do. This proposal does not involve forking at all as I mentioned before. Forking and unified processes are not incompatible. Many of the the Linux kernel maintainers have their own tree that they maintain, but they mainline kernel tree is the one that matters. > > > > 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. > > > > The nature of decisions the CG intends to take are of direct relevance > to all the CGs under OS.o > With the current structuring of the CGs & projects, this particular CG > should at best facilitate decision making by taking inputs from > various other CGs. It should be obvious that promoting "healthy" "sustained growth and success" implies working with other Community Groups. The proposal has also made it clear that such would be the case. > It should do initial investigations on policy-level proposals related > distros and provide recommendations to the OGB instead of seeking > delegation of power. If the CG seeks delegation of power, then the CG > should have a appropriate representation as its core-contributors. This group is a place for Distribution Projects to live. There is currently no appropriate place for Distribution Projects. Thus, this proposal. As a result, the aforementioned investigations are not needed. > > 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. > > > > A distro is a combination of host of technologies and methodologies. A > CG defining unified rules/processes, attempting to enforce them, and > providing guidance when there is no such expressed need is against the > ethos of open source. That seems to contradict your earlier assertion/implication that there cannot be a fork of the main ON tree (which this proposal does not seek anyway). A Community Group by its very nature implies guidance and collaboration. > If the DC & IPS technologies are compelling enough as they are turning > out to be, alternative tools will not materialize or will die. Success > is to be through compelling technologies not via diktats of the people > who are not directly working on *that distro*. Again this seems contradictory to your earlier statements. If branches or forks prove to be compelling, then should they not allowed to be successful instead of being killed before they can even begin? > > 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. > > > > Encouraging people to participate at OS.o is good. > But incorrect reason is attributed to the past problems. > Tools that are used to build Indiana are reaching maturity. There are > no attempts to create a distro at OS.o without using these tools. They > are no reasons to believe existing distros outside OS.o will join OS.o > if this CG materializes in its current form. > Infact I believe the contrary is true, but this needs to be verified > with the distro leaders themselves. That isn't true. Nexenta, SchilliX, and Belenix were all built without these tools. As for saying existing distributions won't join; therefore you don't need a community group. That's a self-fulfilling prophecy. Making such an assertion assumes failure; I cannot agree with that. > > 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) > > > > > > The role of a core contributor in this CG does not enhance the ability > to contribute but does provide considerable rights. While all the > members listed above have contributed to OS.o in different ways, for > the purpose of this CG, the initial core contributors are to be > considered based on *established record* of existing contributions > towards distro related technologies instead of a future promise of > participation/contributions. Additional members can always be co-opted > by the initial set of core contributors. I believe the below subset > from the above list is recognizable: The list given was based on an *established recored* of existing contributions towards distribution related technologies. I am the only exception that I am aware of, and only ask for such a grant for this community because I am volunteering to take on the responsibilities of a facilitator. Therefore, I respectfully decline your version of the list. > Representations from Nexenta & MartuX is missing. Are they required ? > Why or why not? I have added Erast Benson for the next version. As for MarTUX; Martin publicly requested that he be removed from the lists here and expressed explicitly that he no longer wished to participate. The list isn't about equal representation; as explained earlier. It is about recognising individuals believed to be significantly contributing to the distribution process whom I believed would be interested in such a responsibility. Thanks for you comments, but I believe you have misunderstood the proposal. Cheers, -- 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
