Philip Brown writes: > James Carlson wrote: > > ... > > In that case, I think you might be misinformed about what "private" > > means in the context of architectural review. It means that it's not > > documented such that someone outside of the project or consolidation > > can use it. > > > > That is, actually, exactly what I'm objecting to. Someone "outside the > project", should be given enough minimal information, to use it.
Note the words "such that." It's documented, but only for the folks doing work in the same area. Again, not "secret" in any way, but simply not documented to the degree that someone less informed about the area could be expected to make decent use of it. Not documented to the standards of a man page or any other official system documentation. > To give a very specific, personal example, of when this kind of thing is > USEFUL: I hear you, and I understand why you're complaining, but I simply disagree. For the case you're citing, a contract was a better way out, as was filing a bug and making sure that the powers-that-be know that having no stable interface is a serious problem with the system. Hamstringing the developers wouldn't fix that problem. I guess we're going to have to leave it at that, because we seem to be going in circles. > (if people want an interface to be TRUELY "private", while they play with > things.. then dont put it in the public opensolaris tree. If, contrariwise, > it is there, then document it to some minimal degree!) That explicitly disallows a set of cooperating projects to share interfaces that they need without nailing those interfaces to a tree. That sounds like a poor result to me. As previous mentioned (more than once, and by more than one person responding to this thread), there's a balance here between making stable things reasonably available to build on and changing things *quickly* to allow for new features. If you go too far in either direction, then the other one suffers. By saying "no private interfaces," you're going too far in the "everything must be stable" direction. The result is either that the owners of those interfaces are unable to change anything (for fear of breakage), or they're constrained in the changes they may make (certain redesigns are off the table, even if they're "right"), or they simply plow on with incompatible changes anyway, and we stop caring about the customers who are damaged in the process. None of those is a good result. Allowing "private" interfaces in the places they must be used helps provide end users with stability by providing explicit scoping. You're right that the pain is that there are things you can't do. But there are other risks that can be worse. It's thus a good thing, and I believe the ARC should retain it as an option. If you'd like to argue against *specific* uses of "private" interfaces, then I think you should be arguing in the context of either an active project review within the ARC or filing bugs against the specific private interfaces that exist that are troublesome. Either would be a more productive path ... in my opinion. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
