Garrett D'Amore wrote: > Joseph Kowalski wrote: > > Is this one of those FOSS cases we are supposed to not get too deep into > > polishing the edges? > > I don't think so. ksh93 is more intrinsically becoming a core > component, that we build our system upon. It has a non-External > commitment. Therefore, I believe it deserves reasonable review. > Furthermore, from past experience, it seems that the project team and > even the upstream sources have been cooperative in making reasonable > changes required for Solaris. And sometimes, maybe even we can benefit > the wider ksh93 audience -- I think at least one of the issues at stake > here impacts all ksh93 on all platforms, not just Solaris. :-) > > (I guess, IMO, I feel like the ksh93 project is more like a friendly > peer project -- akin perhaps to something like Java or the C compilers > -- than an FOSS project where we are nothing more than a strict > consumer. If the ksh93 folks think differently, I'd like to hear so.)
Technically I agree... but please note that both David Korn and Glenn Folwer have veto rights and reject stuff for their codebase and that the ksh93-integration project has "we don't fork the ksh93 code" as one of it's _major_ goals (learning out of the _painfull_ experience that Solaris's ksh88 codebase was literally hacked to death and making that ksh88 interpreter partially incompatible to ksh88 versions on other Unix versions. That's the reason why we have the ksh93 test suite fully integrated into OS/Net and even _ship_ it so customers can see themselves that we honor that gurantee). We want to pass the ksh93 test suite as defined by upstream to make sure ksh93 scripts written for one platform can run on Solaris, too (and ksh93 scripts written for Solaris may be able to run on other platforms like Linux or Win32/SFU/Cygwin, too). In a similar manner we want to pass the POSIX shell test suite and we do not want to break it and even reject any changes which would cause such breakage (I'm currently even preparing an ARC case which says that the POSIX shell parts of ksh93 are a "commited" (!!) interface (which partially aims at Indiana where the goal would be that /usr/bin/sh is a POSIX shell (that's the same goal as the Linux/LSB folks aim at with "bash" in POSIX mode and "dash")) - which mean that authors who only rely on features defined by the POSIX shell standard can rely on working on an interface with "commited" stability). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
