Josh Hurst writes: > Few examples: > Why is it required to remove .so and lint libraries?
We're currently discussing it. The issue is that the libraries in question are _NOT_ documented, and are not guaranteed any sort of stability to those building separate applications. As they're not documented, they're "private" to the project or the consolidation. Nothing outside should be trying to use them. Why provide conveniences like those that just cannot be used? Those who do use private interfaces inappropriately are just going to get hurt. If the project team actually _wanted_ other projects to use these libraries, then the right answer would be to make them "public" (as part of ARC review) which necessarily means supplying documentation and stability as well. In other words, ask the project team why they don't consider those libraries to be stable things upon which other projects should be building. My guess is that they're not that way today, for an initial integration, but might be so in the future. > You don't do that > for X11 even when the API is not public. If X11 is delivering private libraries with compilation symlinks and lint libraries, then that's a bug. They ought to be removed. > Why is is necessary to demand the removal of diff files from the > source tree even after the project team has begged Sun to leave them > in? "Demand?" "Begged?" I can't quite put my finger on it, but something's amiss with the verbs here. Several folks have questioned the utility of having a set of diffs in the ON source tree. The diffs can be recreated at any time if necessary, they aren't used as part of the build (and are thus dead wood for everyone else), and other projects that have done similar things (at least those that did it _intentionally_, and not just by accident) have found that the diffs really aren't as useful over time as was originally imagined. You're looking at the details of a code review and apparently somehow extrapolating an evil anti-ksh conspiracy out of it. In that, I think you're misguided. > Why are 3 Arc cases required for one shell? There's no requirement to have multiple ARC cases. In this instance, the project team chose to change what they're planning to deliver after the ARC had voted on the first case. That required follow-ups to amend the project. The three cases in question are these in PSARC: 2006/550 Korn Shell 93 Integration 2006/587 /etc/ksh.kshrc for ksh93 2007/035 ksh93 Amendments That first case describes the bulk of the project. It's the only full case in the list (the other two were fast-tracks). The second case outlines something that the project team decided to do _after_ submitting the first case for review. It sets a default editing mode. The third case was added because the project team realized that they needed their own getconf for testing, and to clarify the delivery of bits required for i18n. Had all of those things been in the first case, then there would have been only one case. However, this pattern is *COMMON* among Sun projects. It's not at all unusual to have one primary case describing the bulk of the project followed by two or three fast-tracks that tweak one or another part of it that has either changed since the original review, or for minor changes in the project scope or delivery mechanism. Again, you must ask the project team why they chose to do this. There's nothing particular about Sun or Solaris that demands how they're running their project. > Why does it take that long to get a simple shell added to Solaris? It's a huge and complex change with many subtle (and not so subtle) interactions. It doesn't surprise me in the least that it takes time to accomplish. However, the level of FUD surrounding it such as you're delivering here *is* a surprise, and quite disappointing. -- 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]
