Nicolas Williams wrote: > On Wed, Jun 06, 2007 at 03:03:03PM -0400, James Carlson wrote: >> Casper.Dik at Sun.COM writes: >>> For one, closed source can export public APIs and the Open ARCs may want >>> to have something to tell about them. >> The APIs are just the tip of the iceberg. Effectively reviewing the >> open portions that share (depend on, supply, use) those APIs very >> often means understanding a bit about how the closed part works. It's >> not as clean a process as simply saying "this part is closed source, >> so use closed ARC; this part is open, so use open ARC." > > Yes, there will be design details that must leak in order to have a > proper open architectural review. E.g., some component uses doors, or > forks, or doesn't or whatever. Typically such details shouldn't be the > sort that should be considered proprietary information, but there will > be cases where they are. > > Ideally the process we setup will be sufficiently flexible. > > Disaster scenario: > > I could imagine a case that integrates into Solaris (with internal, > closed ARC review), then tries to integrate into OpenSolaris, is told > "not without open review" then the open review requires changes that > would be incompatible with what was shipped in Solaris, or the team > refuses to undergo open review, at which point: impasse.
That is one of the reasons closed review is not a good thing for anyone, yes. However, I can't imagine many situations where the delay between the two events would span a Solaris release. > One solution then would be: the team distributes their stuff > separately from OpenSolaris (both in Solaris and as an open source > project separate from OpenSolaris). > > That wouldn't be forking -- the fork already exists -- but it > wouldn't be very nice because then you can see different OpenSolaris > distros making different choices as to whether to include the > separate component or not. What Distributors deliver is their own business, I'd like to see uniformity, but it can't be forced. > Another solution would then be for the OpenSolaris ARC to bite that > bullet and accept the component as is or with backwards-compatible > improvements. I think that's case specific. I can't immediately think of a case where *I* would force changes that the ARC didn't force anyway, but of course that isn't to say such a thing would never happen. Resolving that would always have to be done on a case by case basis. > Another would be for the Solaris PAC to access the OpenSolaris ARC's > backwards-incompatible changes and break the interface stability > commitments made by the team in Solaris. Etc. I assume that should read "that break" not "and break". I don't think anyone on the outside is interested in breaking those requirements either, though I could be wrong. That same goal is one explicitly outlined on opensolaris.org. > One thing to do might be to say that all projects that undergo only > closed review can only integrate into Solaris and must allow > incompatible changes at minor releases or even at micro/patch releases. > That would You have text missing here, but that would deal with the "forced incompatibility" aspect to some degree, but I'm not currently seeing that as a likely scenario. >> 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. >> cases (such as, say, LDOMS) where understanding the details of the >> open parts necessarily depends on having a broader view. > > I'd argue that your example (LDOMS) is one where the whole thing should > be run openly. Today that might not be the case, but eventually it > would have to be (again, unless mgmt clarifies just how much openness it > wants and we build the result into the OpenSolaris charter -- I'll stop > adding that caveat now). Given I can't see the LDOM cases, I'm not sure. Wouldn't the firmware side be exposed via OpenSparc, and the software by OpenSolaris? If that's the case, there's certainly no value in that situation to run the case closed. Part of the problem is that those of us on the outside can't see any good example of a case that has real reason to be closed (because we can't see them, of course). The situations I can come up with where code would be open, but cases would *need* to be closed, regardless of wording, are few and far between. 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. >> That's where we're shoving people into a corner. As I said before, >> there are multiple possible schemes you can use, but all of them have >> faults. > > Yes. Certainly, I'm not sure they have more faults than the current scheme, when viewed from an OpenSolaris point of view, however. Something I've mentioned to others before, is that closed cases are actively detrimental to Sun and the source base. It precludes a section of active developers from seeing information that may be important to the changes they are making, that can only increase the chance of problems. Openness here benefits everyone, including Sun and the Solaris product. -- Rich
