* Shawn Walker <[EMAIL PROTECTED]> [2007-02-01 07:52]: > > Nobody likes the closed_bins; but it's not under our > > control.... > > I think what's most frustrating about the closed_bins is that we don't > know *why* in some cases. It would be helpful if there were a status > list for the closed_bins that indicated what items would never be > available (due to 3rd party or something generic like that as reason), > which have a chance of being available at some unknown date (under > review), and which items will be available at some unknown date (in > process). > > That would go a long way to silencing critics. If we *knew* that you > actually couldn't release an item ever because it was completely out > of "SUN's hands" so to speak; that might be a motivation for people to > start working on something. At the moment, we have some vague notion > that some things are "out of our control" but we don't know who the > group of people the comprise "our" is, and we don't know if that means > *forever*. > > I apologise if this information is somewhere obvious and I've missed > it. > > Thankfully though, we finally *know* that libc_i18n is completely out > of "SUN's hands" so to speak. It indeed sounds like a great > opportunity for a community project.
If a contract carries terms of confidentiality or non-disclosure, then the signatories can't tell a third party the specific details you seek. I suppose my question is: why not just assume that a non-SMI-led effort to provide an OSS replacement for each and every closed binary is needed, and then order them by interest, necessity, or some other priority? For each consolidation publishing closed binaries, you have a list. Start the projects to reduce the reliance or inclusion of encumbered components. As a non-lib example, for instance, it's been suggested that ON be scrubbed of its ksh88+smi scripts--replaced with tested ksh93-based versions. This means that distributions would be less affected by restrictions around ksh88+smi binary distribution. (That's a shell scripting project, which probably has the opportunity to also look at identifying common shell scripting style and practice for ON or other consolidations (if the hypothetical project team were interested).) Similar cases can be made for other encumbered components. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ opensolaris-discuss mailing list [email protected]
