Peter, >> With respect to CCD and SFW, I've been thinking along the same lines. >> In general, I completely agree with this although longer term I don't >> see a need to introduce any more CCD packages. Instead what I would >> propose is that all such externally-derived open source be integrated >> into the SFW effort. CCD could continue to exist for Solaris 10 but >> for future releases, externally-derived open source could come through >> SFW. > > I don't like this. The problem with it is that if it follows existing > practices > with SFW, then the stability constraints rapidly result in fossilization.
First of all, the SFW I'm talking about is similar but not the same to the SFW we've had in the past. To clarify, I don't believe the effort being run out of SFW precludes differing stability constraints. In fact, my assumption is that there will be software of various stabilities integrated through the consolidation. Certain pieces of software - for example, libxml - may change more slowly than other pieces of software and will not change incompatibly. Other pieces of software might change incompatibly at a Minor release boundary (for example, SunOS 5.11) but then would not over the lifetime of that particular Minor release. And some pieces of software may change much more rapidly. > Now, either we can get to a state where we can rapidly integrate new > versions of software into the stable SFW tree very soon after their > release (which seems unlikely, given that much of the software we're > talking about doesn't have strong stability guarantees), or we need > a separate track into which the new versions can be injected. And yes, > this will often mean that there are multiple versions of the same app > on the system at the same time. I don't believe SFW precludes supporting this sort of effort. Previous efforts have tended to deliver software which was fossilized but there is recognition that this needs to be addressed. > So I think we need at least 2 different efforts. What the second > one ought to be based on I'm not sure. > > (And yes, even for the software I myself build and maintain, > I usually find myself maintaining multiple versions - one for > stability and maintaining dependencies, and a second to get > all the new features, and maybe others.) A number of us have been discussing as a requirement the ability to support not only multiple versions of software but also multiple streams of change - this would allow certain users to ride the slow-moving train which changes slowly over time and large and/or incompatible changes come at very well defined points. But it should also allow a class of users who desire much more rapid train - for example, a user accustomed to the Solaris Express biweekly release. Even more risk tolerant users might choose to live on the "nightly" train. dsc
