>>> 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. > > 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.
If you do not allow closed review, you are practically begging for teams to circumvent the process in order to keep information private. Essentially, the teams in question have two legitimate goals: get effective, timely review; and keep proprietary information private. If your process makes those goals mutually exclusive, and the second is mandated by contract (or patent law or whatever), then your process is effectively denying the first goal. > 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 agree that "we're XXX-internal" is irrelevant (or at least orthogonal) to the need for review. I don't really think that's the common case here. >> That's just not how the system was designed to work. If it's used >> that way, then some very bad things happen. Either the ARC is >> "forced" to accept something that's wrong because it's just "too late" >> to fix it, or the project team is given TCRs that they can't (or >> won't) implement, and it then becomes a political issue. The results >> are _always_ worse that way. > > 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). You can prevent successful end runs by having, and appropriately exercising, authority. You can minimize attempted end runs by crafting a process that enables teams to achieve all of their goals, and then using that process to facilitate that achievement. It doesn't happen overnight; teams will initially be suspicious of your motives, and will not understand the value you provide. >>> ... But Sun, in particular, has an OpenSolaris-derivative product >>> (Solaris itself), and I think it behooves Sun not to run closed cases >>> that integrate into the closed portion of Solaris just to avoid public >>> exposure. >> >> Really? And management agrees? > > I really think that; I don't know if management agrees. You cannot address this at the process end. The process must facilitate the needs of the community. In this case, there are folks inside Sun (and eventually XXX-corp) who need to avoid public exposure. You can only fix that at the source: the real or perceived need to keep information private. Until you fix that, a process that prevents it will not succeed. >>> 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? Yes. It's broken for the reasons I described above. You're talking about giving a project team an ultimatum: either break your legally binding contract, or forego architectural review. That's a crappy, broken process. > 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. If the problem is the corporate need to keep information private, then the solution lies with the corporation, not the process. I think it's disingenuous to deny that need, and I think that trying to force change by implementing an incompatible process will result a process that is not followed. --Mark
