> What does it mean for the /bin/sh problem? Maybe you or Ian should > make an executive decision: Pick a shell (ksh93 or bash) and get it > integrated as /bin/sh.
That's not how it works with OpenSolaris. Instead, someone in the community needs to make a proposal to change /bin/sh to something different. The process in complete detail is listed here http://opensolaris.org/os/community/on/os_dev_process/#development-process but the general idea would be to 1) Propose something on the appropriate OpenSolaris mailing lists. For something like changing /bin/sh which has many consumers, you'll need to get a fairly wide representation. Some of the issues that need to be explored are Which shell should be the replacement? What are the system dependencies on the old /bin/sh? Are there any upgrade issues for existing users (per-user dot-files, personal shell scripts?) Is there an upgrade strategy that makes sense? How will this change be communicated to the community, ISVs and existing users. 2) Once a consensus has been reached about the particulars, then some sort of design should be articulated. In this particular case, it might be a refinement to the original proposal to document what's being delivered, the impact of such a change on the system and what, if any, upgrade procedures need to take place for existing system. This along with a list of the "interfaces" that the new proposed /bin/sh "imports" (or consumes) and "exports" (or provides to other consumers) could form the basis for an ARC review. 3) In parallel with this design/architectural statement, a test plan needs to be drafted and reviewed which when executed tells the implementor and eventually a review team (called the C-team) that the replacement works correctly (by any number of notions be it test suites, standards conformance tests, etc). The test plan also would cover regression testing of other components which use /bin/sh to verify that they're unaffected by the proposed change. If those components are affected, then part of the project would be to fix them to work with the new shell. 4) Once the revised proposal has been approved by the ARC (in this case, PSARC), and the test plan has been executed successfully, there would need to be some sort of code review for all proposed changes (even if they're just packaging changes). With a change of something as fundamental as /bin/sh, there would undoubtedly also be documentation changes to the OpenSolaris books, the appropriate manual pages and other documentation source which "announce" changes in OpenSolaris. 5) Current test suites for OpenSolaris would need to be updated to accommodate the revised /bin/sh and in addition, new test suites should be introduced to make sure that future putbacks don't break the newly revised /bin/sh. 6) The last step is typically C-team review which verifies that the implementor has done everything they were supposed to. dsc _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
