Roland Mainz writes: > James Carlson wrote: > > Given the cost of the effects and the > > still-not-certain-we'v-fixed-it-entirely state, I think he has a good > > argument for a reversion until the project team can show that the > > change actually is safe. > > I, April and others ran the ksh93 test suite, the VSC test suite, > building OS/Net, SFWNV, KDE, FOX, X.org X11R6.8+lots of Sun-internal > stuff with /sbin/sh==ksh93, did manual testing and we had binary test
Please re-read what I wrote. I'm not suggesting in any way that you didn't test. Nor do I think anyone else is suggesting that. What I *am* saying is that I agree with meem and the other folks who have commented here to say that the on-going problems have been far more widely felt than anyone could have predicted. The issue is the state of the system now, not the history that got us here. At some point, surely, we have to take a step back and ask whether we're on the right *short term* path to go forward. I think the questions you've seen here reflect exactly that concern. It's not a question about long term path (Mr. Szczesniak is plainly mistaken about that), but about what should be done to mitigate the problem until the problems have shaken out. > If you now request to remove the "one change" then it may be nice to > answer the question how should we test this if we can't get bug reports > anymore ? And how should I test all possible test suites which are > locked behind Sun's firewall ? Technically your request to "show that > the change is actually safe" cannot be 100.0% done since noone (not I would suggest having all of the folks who have been affected so far run test (repaired) bits to find out whether there are still more problems, or if this was somehow the last of the issues. I agree with you that there's a problem in testing "everything." That's just not possible. But it is possible to list the things affected so far, and make sure those things are retested before driving on. > > As for the "moratorium" idea, the general problem is that the system > > is supposed to maintain FCS quality all the time. > > ... and we try to met&&honor this rule at all cost (guess why we needed > 14 months between the two ksh93 putbacks ?). So far after all the > testing ksh93-integration update1 got the "green light" for integration > into OS/Net. You really can't claim that we violated that rule. I'm not claiming any such thing. I'm claiming that rejecting out of hand the suggestion to back out only the /usr/bin/sleep change is itself such a violation. When we learn new facts, we should adapt rather than hide, shouldn't we? > Finally: I really would like to work on the code and not on a giant > stream emails. What I really would prefer right now is that people here > come up with bug reports (including steps to help us to reproduce > problems (like Casper does) and not bomb the list with further > discussions about the wrapper architecture behind /usr/bin/sleep. And I'd like to see at least a small amount of respect granted to the people who are asking if there isn't some short-term relief that can be given in this instance. I still do not think that meem's or Dan Mick's questions were beyond the pale. I'd expect those same people to approach me about any bug fix I'd made that has unintended consequences, and I certainly wouldn't assail them with nonsense claims that they're "stopping innovation" or any such rot. Why is this particular case special? -- James Carlson, Solaris Networking <james.d.carl...@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 _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
