Nicolas Williams writes: > On Wed, Jun 06, 2007 at 10:32:39AM -0400, James Carlson wrote: > > Keith M Wesolowski writes: > > > Consider the alternative: a MegaloCorp project team engages in > > > confidential review early in the life of its work, and does its work > > > in secrecy on the basis of that review's results. At a later time, > > > when the project is complete and has been approved within MegaloCorp's > > > processes, the team is new ready (based on whatever criteria it or > > > MegaloCorp chooses) to share the code with the rest of us. Prior to > > > integration, we require an open architectural review of what is, for > > > all intents and purposes, a completed work. > > > > Indeed. It's not acceptable as an open process. ... > > 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!" 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. It doesn't work for all the same reasons that showing up at a communities doorstop with a fait accompli doesn't work. What you're describing is essentially a failure mode. Making the failure mode the normal case for an entire class of projects seems like a mistake. > > ... However, after > > switching s/MegaloCorp/Sun/g, there are practical problems to consider > > -- Sun can't just sink because OpenSolaris tells it to. I don't know > > what the balance might be, but that doesn't seem like a viable answer. > > ... 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? > 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. > > So, while we're forcing Sun management into openness, what's a > > "Fishwork?" :-/ > > I think we're forcing Sun management to understand and live with the > consequences of the openness policy that they themselves have set, > rather than forcing them into openness that they are reluctant to > accept. Here one consequence is that running ARC cases away from public > view detracts from our stated policy of openness, so, which is our > policy really one of openness? I think it is, but we're still > transitioning; the window of opportunity for closed cases is closing > fast. An interesting viewpoint, but I don't know if it's widely held. -- 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
