James Carlson wrote: > Roland Mainz writes: > > James Carlson wrote: > > > In any event, it doesn't make sense to me to cram this into an > > > unrelated set of changes just to get it integrated. If the problem is > > > "I can't get a sponsor," then let's try to fix that problem instead. > > > > It's not a "I can't get a sponsor", it's far more likely "I can't get a > > RTI". Technically the issue boils down to the term "propper testing" - > > in theory we would have to test all possible codepaths for this change > > which is almost impossible for an external contributor. The part which I > > can test is that Solaris boots, runs, shuts propperly down and compiles > > OS/Net and passes the ksh93 test suite without triggering coreadm to put > > a dump into /var/core/ ... but doing more becomes tricky... finally we > > concluded that I can only gurantee 98% of 100% required for a normal RTI > > approval, leaving one or two possible bugs behind somewhere in the tree > > (and we don't have the equivalent of a tactical nuke to drive the > > remaning bugs out of their holes... ;-( ) ... > > If you can't adequately test your changes, then I would suggest not > making them. > > In other words, if you can't (or just won't) actually test that you > haven't damaged some existing bit of code that you're changing, then > it'd be a much better plan to avoid the blank change, and instead > enable -xstrconst in *just* the places where you are able to test your > changes, letting someone else handle the parts you aren't testing.
W had that discussion long ago with even a "stronger" requirements, e.g. enable "-xstrconst" manually for each single source file which has been explicitly reviewed. If we keep this kind of requirement up (or your suggestion below) then it will be impossible to implement the "-xstrconst"-change. That's why the project is currently stuck in an endless loop of discussions. We can only move forward if the testing requirements for this putback get lowered to the same level as used for an compiler update (that's why it was suggested to catch the "switch OS/Net to Studio12"-train). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
