Richard Lowe writes: > Nicolas Williams wrote: > >> It'd be nice if it were that simple, and perhaps it is in some > >> restricted cases (particularly where the closed source just implements > >> some standards-defined bit of functionality). There are many other > > > > That will be rare. > > With the exception of libc_i18n, I think it incredibly unlikely to ever occur.
Actually, I don't think it's too rare. We can start with the "special cases" of WiFi drivers that must be held as secrets due to regulatory issues, but where the interfaces used and defined are set up to be standards. Another example might be Java and the JCP. My point was that if you have a common meeting point, and that meeting point (such as a standard) is well-specified such that we really don't need to look past it, then we've got a good splitting point for open and closed reviews. If you don't have that clean break, then things start getting ugly. You start seeing project details leak out in dribs and drabs in tiny ARC fast-tracks -- and that's a break in the process, because it robs the ARC of context. > One thing to consider is that information in your case is what affects its > confidentiality, if you needlessly provide confidential information, you're > hurting nothing but yourself at that point. > > How often is necessary architectural information also by necessity > confidential? Someone must have a vague idea here. It is a problem. In some cases, it's just reflexively confidential. Sometimes, nobody really knows. Keith M Wesolowski writes: > part of OpenSolaris and entitled to special treatment. If that > assumption goes away, as when one contemplates the Nexenta example, it > becomes much clearer that these secret codebases have to be treated as > opaque objects irrelevant to and separate from OpenSolaris. If we're > not able to tolerate the reduction in review quality that this > distinction entails, what is the alternative? Yes, I've been making that sort of assumption all along. The problem is that there's a pretty big gap between that ideal (and that logical conclusion) and the necessarily broad scope of architectural review. > > So, while we're forcing Sun management into openness, what's a > > "Fishwork?" :-/ > > We're forcing Sun management into openness? That's not what you were suggesting, but it's what some of the other posters were suggesting. > Here I thought we were > trying to set policy around OpenSolaris. What FishWorks is is hardly > an appropriate topic for this list, I agree it's not. It was a comment on the existence of non-open development. Others have been suggesting that there either shouldn't be any or that it somehow doesn't matter. It exists, and it does matter. > we've at times found it useful to change that technology; I have > offered those changes up for public and open review. My comments in > this thread reflect the expectation that others similarly situated do > the same. Yep. Unfortunately, not all things are so easily cleaved. Perhaps more importantly, it means that people doing architectural review on those bits lack the broader context. One of the important points of ARC review was to expose the broader context. That doesn't (and can't) happen when there are walls. -- 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
