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. As an example of this sort of longer-term task, see CR 4444249: http://bugs.opensolaris.org/view_bug.do?bug_id=4444249 Someone long ago filed a bug saying that we're not linting cmd-inet. Rather than try to fix that all in one swell foop (possibly breaking all sort things, and likely not testing anything), we've been filing individual bugs for the components located in that source directory, and fixing them one at a time. Once someone fixes "the last item," then the overall bug will be closed. The same could easily apply for a blanket change such as turning on -xstrconst. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
