Hey,
Shawn Walker wrote: > 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. 100% agree with this. There are a lot of current OpenSolaris based distributions already out there and having an umbrella Community Group to encourage collaboration between them and encourage working with 'upstream' seems like a good approach. > 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. I expect most distributions will be relatively isolated in terms of what their priorities are and how they effect other distributions, nor would I expect many disputes to happen - but what you say should certainly be in the bounds of most Community Groups. How might, for example, Solaris fit in? :) > 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. Sounds fair to me. > 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. I agree with the desire to encourage patches to get upstream in a quick and effective manner - our request-sponsor process to date has been anything but ideal. However, I don't necessarily see the need to include this in the proposal, though it's great that you're concerned and wanting to do something about it. The issues with request sponsor isn't necessarily related to distribution-only problem - other people are submitting patches outside that and having similar difficulties. Furthermore I think most distributions are going to have entirely different sets of priorities in terms of what builds of ON (or other consolidations) to choose - that's their decision, and I think the problem of patches is best solved upstream, rather than at a distribution level. Glynn
