On Jan 20, 2008 10:13 PM, Brian Gupta <brian.gupta at gmail.com> wrote: > 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.).
Those individuals are not represented merely because I don't know they are or because they don't participate within the OpenSolaris community to a point where they are visible to me as someone that would be interested in distribution decisions. It is merely a proposed list and other individuals that feel they should be considered for core contributorship are free to ask. The list of people isn't about "representing" everyone who might be involved in distribution creation so much as people that are heavily, actively involved in the creation or support of distribution projects. > 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. The proposal for a Distribution Community Group has nothing to do with Indiana-based distributions. You can't bypass ARC for OpenSolaris as it is not a required part of the OpenSolaris processes (yet). Nexenta, SchillIX, Belenix, are all "forks" right now. > 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.) I'm rather lost on this point. The new initial project in the proposal (that is only included as a reference) does not refer to Indiana, and does not use any Sun trademarks. The Distribution Community Group itself would merely be a place to represent distribution projects. > 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? The proposal is only about the creation of a Distribution Community Group. ARC does not apply to OpenSolaris; see recent postings by Roy Fielding. The remaining concerns you have noted are something to be dealt with by the Distribution Community Group (if/when it exists) and the core contributors of any distribution projects. They are outside the scope of this proposal. > 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. Correct. > 2) What resources beyond the scope of a project does Indiana need? It isn't an issue of resources. > 3) What is wrong with the scope of the current CGs that are sponsoring > Indiana? As others have pointed out, Indiana being attached to the Desktop Community Group doesn't make a lot of sense in the grand scheme of things. In addition, the decisions related to distributions impact the entire community, not just the Desktop community .Therefore, it makes more sense to have a community specifically devoted to Distributions with certain powers delegated by the OGB to promote the sustained growth and success of distribution projects. > 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.) No. The primary point of the initial project that was proposed (only as a reference point, again) is to create a place for developers to innovate and experiment with a very low barrier to entry. Developers will be encouraged to integrate into the main ON gate or to relevant projects at a later date, but will not be bound by whatever perceived restrictions there are today while they experiment. The goal of creating this project is to mirror that of the iterative processes that are typically found in other open source projects. > 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). I'm not aware of any "Indiana-specific" tools that exist currently. Indiana is primarily an aggregation of projects from the OpenSolaris community and does not have any code itself. See recent postings on the Indiana list asking about how someone could contribute; the answer was to contribute to the relevant projects that Indiana uses. As far as using these tools being a requirement for "membership"; no, that would not be the case. The Distribution Community Group will certainly encourage unity among Distribution Projects and seek to prevent fragmentation. But innovation, success, and growth are the primary concerns. The core contributors of the Distribution Community Group are whom would approve the creation of a project. The proposal does not attempt to pre-define any policy for project creation or disbandment. > 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.) They are outside of the scope of this proposal. However, past issues might include the lack of direct involvement by third party distribution developers (such as Nexenta not having a project on opensolaris.org). > 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? Projects need guidance. Their sponsoring Community Group is supposed to be part of that. Community Groups work to promote a healthy relationship between their sponsored projects and the rest of the community. > 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. It is not. In addition, I only took two names from the Indiana Project page. The names were taken from various project pages such as caiman, ips, installer, etc. The core contributors for a community group aren't about "equal representation"; they're about recognising a set of individuals who have a high contribution to a Community Group's activities. As others have pointed out in the past; well-scoped community groups are better for projects. Too many members with voting rights will paralyse a group from being able to make decisions due to a lack of consensus. -- 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
