S h i v 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 public comment period. You could ping the core contributors list if you felt so inclined. My personal feeling is that those that are interested in governance will be watching the governance list. I've refrained from sending mail to the core contributors list regarding this or other issues that I feel may not be of paramount interest to *everybody* on the list (and I stress everybody, since there is no way for people to opt out of that list). > 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. > As much as I would like to relive the Indiana controversy, I don't recall advocacy group members claiming exclusive product management right and/or expertise. Happy to be proven wrong though if you have pointers to threads I didn't read (and I'll be the first to admit I didn't read every single Indiana related thread). I would find such claims to be enlightening and educational. > 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. > I don't read Shawn's proposal as forking. It's not any more forking than all the project gates that ON development teams keep all the time. Up until build 78 or whenever Xen went in, there had been a "forked" Xen gate for ages. Likewise for any other large development project.
If the aim is to let rapidly developed changes "soak" for a while before pushing upstream into the main ON gate, then I see that as a good thing, and not any different than what current ON development teams already practice. >> 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 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 sounds reasonable to me. Though I'm not certain the OGB is any more qualified than the CG would be (and arguably less so). cheers, steve -- stephen lau | stevel at opensolaris.org | www.whacked.net
