(Trimmed the cc list.) John Plocher wrote: > Garrett D'Amore wrote: >> unison as documented for this case, IMO, does *not* belong in any >> default distribution of Solaris, but in some value add location where >> folks who want it can get at it easily. > > I tend to agree.
Ah, the value-add location like we had with /usr/sfw/gcc or value-add repository of /opt/sfw? Seriously, please consider the gcc example illustrative. Even though it was *bundled* people didn't (still don't) think Solaris shipped with it. Making software harder to get or harder to find isn't necessarily the right answer. But I'm not even convinced the ARC should be in the business of deciding which software is 'bundled' in the distro, versus what's in an 'alternate' repository. (And having ARC banish it to another consolidation is equally bad -- consolidation boundaries should be able to be set based on development efficiencies.) Shouldn't ARC just be in the business of reviewing a project team's definition of how stable and architecturally integrated an included piece of software is? If the software is developed externally, it's a matter of making sure the project team communicates to users (not by location, but by documentation) when they're building on quicksand. Heck, isn't that even true of OpenSolaris-specific software? Why should ARC spend much of its time second-guessing whether interfaces should be at the stability the project team defined them at? Sure, there are times where project teams misunderstood the stability levels, but they're probably not even the rule. A bias towards stability is certainly appropriate, but it's not even practiced for all OpenSolaris-specific software today. (Feel free to ignore this paragraph rather than quibbling with it -- it's probably tangential.) We're getting to a world where creating distributions is much easier. I hope that ARC will spend its time classifying interfaces and components so that administrators, developers, users and distro builders alike can make educated decisions, rather than having ARC attempt to define the exact contents of a distribution. John, I think the rest of your mail is a good way to start attacking the problem. But I'm very wary of the idea that banishing non-ideal software to another location solves anything. Focusing on what ARC *can* do to classify seems like a much better approach. (Especially when those classifications can be categorized and fast-pathed so we don't see the same discussion in every ARC case.) liane
