James Carlson wrote: > Dan Price writes: > > On Thu 28 Sep 2006 at 02:56AM, Roland Mainz wrote: > > > > If yes, what is the rationale for doing so? > > > > > > The idea was to have a tool which customers/users/developers can use on > > > their side to verify that ksh93 works correctly before calling support > > > and complaining that there is something "broken". > > > > I guess I would argue from precedent that this isn't the way we have > > tended to assemble the product. I personally am not aware of any other > > test suites shipped by the WOS or ON (but I'm sure in some dusty corner > > there is one). > > Agreed on all those points (particularly about _not_ having end-users > "testing" the system,
Erm, the majority of people who use Solaris Nevada are developers and it may be usefull to get their feedback. For example if the i18n-parts of libc are broken it may be helpfull to have the test suite around to narrow-down the problem. > as that's likely not a good way to build > confidence that we're actually doing our jobs), Uhm... why do you give tools like "dtrace" or "truss" to the end-users ? :-) :-) > but a fair compromise > might be to let this in temporarily on the condition that it > eventually migrates over to the test consolidation -- once that > consolidation is actually open. Mhhh... the test suite is included in the ksh93 codebase and should remain there (unless there is a way to keep both codebases in sync and prevent users from running the wrong version of the test suite against ksh93) - moving the code to a seperate codebase is tricky as the test suite and the ksh93 version must be exactly in sync - it is IMO useless to run the shell against a different version of the test suite. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
