Nicolas Williams writes: > On Wed, Jun 06, 2007 at 12:15:31PM -0400, James Carlson wrote: > > Nicolas Williams writes: > > > But any project team can setup their own internal architectural review. > > > As long as they are required to do a de novo architectural review > > > through the OpenSolaris ARC in order to integrate into an OpenSolaris > > > consolidation that's just fine and dandy. > > > > It does great violence to the ARC process to have completed projects > > show up on the ARC doorstep marked, "hi! please approve me!" > > I think you misunderstood what I meant.
That's ok. I think you misunderstood me, too. ;-} > I'm not arguing that any project team should do this -- only that noone > can stop them from trying, EXCEPT that the OpenSolaris ARC must have the > authority to deny/issue TCRs. That's not the problem. The problem is not a matter of authority. It's a matter of making things work _well_. The current process assumes that everyone is acting in good faith and is doing things in the best way possible. It falls apart if they're not. In particular, if people show up late to ARC review (in terms of their project development), then the depth and quality of the review suffers, and the results are poor. We should not build that into the way we believe projects should be reviewed. We go out of our way to try to educate project teams about how this is supposed to work, and why it needs to work that way. Why would we intentionally break that? > The project team might feel entitled to rubber-stamp approval because > they are Sun-internal or MegaloCorp-internal (for a MegaloCorp with an > OpenSolaris derivative), but I don't think the OpenSolaris ARC should, > or would, do that! Certainly I hope it wouldn't. I don't think so, but then we suffer with all the problems that late reviews cause. > But I don't see how OpenSolaris can prevent project teams from believing > that they can take this tack -- OpenSolaris can only refuse to > rubber-stamp (and it should). Right. But we shouldn't build this lameness into our assumptions! "ARC early, ARC often." > > > Sun projects that wish to stay out of the public view until ready should > > > just fine tune their timing in view of the need for running ARC cases in > > > the open. > > > > That, in my opinion, is just plain broken. > > Huh? What's broken? Are you saying that we need closed ARC cases? Our management sees a need for projects that are closed. That much is obvious. Some of those projects involve coordination across both open and closed source. The question is what to do about that. Closed ARC cases are one possibility, but they certainly cause problems in other areas -- such as with OpenSolaris governance. Paired open and closed cases cause other problems -- such as complexity and lack of substantial open review. "Forcing" late open reviews cause the reviews themselves to be of poor quality and questionable usefulness. I don't see simple answers here. > The decision to open Solaris came from the top, from Sun's CEO. Ergo > Sun management adopted an openness policy. Perhaps all the consequences > haven't been worked out and perhaps Sun management may change its view > on openness, but for now the dictum we're working on is that we're > trying to build an open community around OpenSolaris -- the dictum is > openness. I agree with that. I just don't think the implications are fully understood, as I suspect that the line between "business" and "architecture" is not well understood. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
