Darren Reed writes: > >ARC review is required, but that's the easy part. Besides providing > >the man page text, the case itself is a one-sentence affair. > > > > The tone of this project (as I read it) is for this interface > to be used by people outside of the local team and to me that > implies that the interfaces should be targetted at being stable.
Not so. "Outside of the local team" is also satisified by having Consolidation Private stability. This means that any other project that delivers via the same consolidation (in this case, ON) can use the interfaces safely. It's even possible for projects that deliver outside of the ON consolidation to use it as well, provided that they get contracts on the interfaces. Though it's desirable (for many reasons) to make the interfaces Stable, it's not actually a requirement. As Consolidation Private, those who deliver *outside* of the consolidation cannot use it safely. In other words, if your plans don't include integrating into ON, you should either not look here, or should talk to the project team and the ARC to get a contract. > Now that solaris is open, we need to be making more effort > to provide good stable interfaces for developers at all levels > to work with so that they aren't encouraged to read source > code and use interfaces that will cause them pain in the future. That sounds like a different sort of argument to me, and probably something you should direct to the Tonic team or the PAC instead. The implication is that open-sourcing the software means that engineering, now both inside and outside of Sun, is constrained in ways that it had not been in the past. It means that where we once used to draw a clear distinction between "visible but you shouldn't use" (denoted "Private" in the taxonomy) and "visible and we want you to use" (denoted "Public"), we no longer have that flexibility. I don't believe I agree with that argument. We should certainly be providing outside developers access to much more than just the source itself, and I believe that we are actively attempting to do so. We should provide more internal documentation on the design of the system itself. The code alone is nearly useless without it. I don't agree that providing internal documentation to the rest of the development team means that the interfaces automatically become "Stable." Nor do I agree that using random stuff you find via grep or nm was ever or is now acceptable engineering practice. All I see here is an expansion of the development team to include folks who aren't on the SWAN. An expansion of the team doesn't mean that the basic architectural principles themselves (such as distinguishing between "public" and "private" or between "project" and "consolidation") have in fact changed. Conflating internal documentation (which, as a matter of sound engineering practice, should necessarily exist for all Private interfaces) with official documentation (which is required for Stable ones) is a mistake. These aren't the same sorts of things, and quite intentionally aren't subject to the same sorts of rules. We have strict rules about the compatibility of Stable interfaces, while Private things can change even in patches. I think the important distinction to draw here is in how the software is put together, not where the people looking at it are sitting. That's what project and consolidation boundaries, and the interface taxonomy based on them, are all about: software architecture, not personnel structure. (The only stability level that seems threatened in this brave new world is "Sun Private." That particular stability level was effectively "actually Stable but we're not funded to write a man page," and thus was fairly strongly discouraged. Maybe we can hammer the last nail in that particular coffin.) -- James Carlson, KISS Network <[EMAIL PROTECTED]> 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 _______________________________________________ networking-discuss mailing list [email protected]
