Jiri Sasek writes: > Exactly... The problem is the gnutls is the part of the JDS even if it > delivers more core functionality than the "window painting". What more.... it > is "internal closed" interface even the "external" is more probably better > expressing the position of this library in "opensource world". This is > ambiguous behavior of the ARCs when they allow such "closing" of the > external-public interface but they does not pushing such "building stones" to > provide better stability to the rest of the ?system?
It's a difficult balance to strike. On the one hand, yes, we in the ARC would very much like to see more of the useful interfaces being made Committed so that they can be used by other projects without fear that the sand will shift under them. At the same time, we cannot in all cases _force_ a project team to commit resources it does not have. Making a commitment to a higher stability level means doing more work: making sure that future changes are understood and made in a way that preserves compatibility. We do encourage project teams to step up to what's needed. We do provide feedback to project teams and management when private interfaces are causing problems. And we even occasionally hold a project hostage to a stability commitment where necessary. Part of the problem here is that we're working with a different set of rules than much of the open source world uses. For most incompatibility problems, the open source answer is "download the newest stuff from our CVS server, recompile, and it should work." That's great for uncomplicated projects and ones where latest-and- greatest is exactly what's wanted. It's not so good an answer if you're trying to engineer a system where old software still works tomorrow. > Being sarcastic I can say ...doing the system means harmonizing the > components to work together ...not make the "consolidation closed" > interfaces. :-> Agreed. The common alternative to those private interfaces, though, is documenting things that may be changed radically in the future, and thus cause applications to fail when the changes do happen. That's not good. -- James Carlson, Solaris Networking <[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 _______________________________________________ opensolaris-discuss mailing list [email protected]
