Milan Jurik writes: > V st, 18. 02. 2009 v 18:56, James Carlson p,Am$,1!!(Be: > > Nobody knows what the problem is (it hasn't been root-caused yet), or > > if any of the later fixes address it, but the workaround is to remove > > the ksh93 /usr/bin/sleep from the system and replace with the old > > binary. > > > > Which is not easy to analyze based on that particular test suite. But > with sleep involved and that test suite playing with NIS+ server and > nscd it is probably CR 6807422, which is based on sleep "~ regression", > CR 6807179. I will try to find some time to look at it later.
Yes, that seems like a fair bet. In any event, meem's original point was not that someone needs to fix every one of these cases individually (obviously, they do need fixes), but instead the point is that as changes go, this *particular* one (changing /usr/bin/sleep) had a substantial blast radius. 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. As for the "moratorium" idea, the general problem is that the system is supposed to maintain FCS quality all the time. There's no such concept in ON as debugging something into existence. Instead, the rule is supposed to be simple: it's either ready, or it's not, and if it's not, it gets yanked until it is. The reasoning behind that is here: http://opensolaris.org/os/community/on/dev_solaris/qual_death_spiral/ Thus, I think meem's questions are on target and entirely fair, despite the grousing to the contrary. The question he's been raising is whether it's time to undo that _one_ change (not the entire wad) until the change can be shown to be safe. As for the answer to the question, I think that this latest problem ought to be the last straw: if the fix works and can be quickly tested in all the scenarios that have broken, then ok. If it fails anywhere for any reason, then yank it until there is a well-tested fix. Enough's enough. ksh93 isn't the only project in the gate. -- 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
