Alan Burlison <Alan.Burlison at sun.com> writes: > Keith M Wesolowski wrote: > >>> out and do it properly. To take your example above, I can see no reason >>> why the DTrace CG would choose to run its projects in another CG - there >>> appears to be no real benefits in that approach. And if the ON CG dies >>> (as it should), it wouldn't be an option anyway. >> >> Please tell us who is responsible for ON itself in that scheme. >> Specifically, who will perform the functions the Sun C-teams performed >> in the past, and by what authority will they do so? > > In the existing Solaris Engineering structure it most definitely isn't > the role of the cteam to own projects. The cteam ensures that > development standards and practices are followed, coordinates the > integration of large project, oversees the operation and building of the > gate and acts as an advisor to project iteams. It most certainly does > *not* own implementation projects. The current ON CG is a radical > departure from that model, not an example of it.
The current ON CG is disfunctional, unapproachable (as a CG), and barely extant. > I have no problem with, for example, there being a Consolidation CG with > an ON Project underneath it, or even having ON as a CG. I do have a > *big* problem with the ON CG 'owning' implementation projects as it > means there is a clear conflict of interests for members of the ON CG > who will be wearing both their 'cteam' and 'iteam' hats. The existing > Solaris Engineering structure provides a vital 'checks and balances' > mechanism that is completely absent from the ON CG. > > The current ON CG is clearly a bad idea, and should be restructured or > replaced. I would suggest that making it function exactly as described above would be a great start. Communities do not "own" projects, they endorse them, and provide advice and guidance, exactly as you described the C-Team giving projects teams guidance above. -- Rich
