On Tue, 21 Nov 2006 15:50:46 +0100 Martin Schaffstall wrote: > It is interesting to observe that each time the project reaches > another milestone a Sun employee steps in and demands a full change of > the project. But it seems Sun now shows its true face by tearing down > the project with unbearable review requests, essentially preventing > progress indefinitely.
there are many forces in play 4 hour mail delays caused by russian spammers and an apparent exponential spamassasin inner loop a bit of perfectionism on the at&t side i.e., a knee jerk refusal to take on/solaris/architecture-foo only patches in favor of fixing problems the right way for the bigger picture the living standards, supplying daily doses of surprise "who wrote *that* code" for anything I did > 6 months ago ksh=>ON is just one of many ksh targets *any* change for ON must pass muster on all other ksh target sw/hw architectures thorough edit-build-test turnaround can be on the order of 4 hours ksh is one part of a larger collection of sw -- some ON integration changes affect that larger collection -- although not in the ON purview, these changes must play nice in that larger collection although this is a new sandbox, there are already many technical guidelines in place, some from the at&t side, some from solaris abiding by the guidelines is better in the long run if there are no exceptions to the ksh ON integration then the downstream users will know what to expect, and will know what to do when portions fail to work as far as testing, even in the ast build testing is a two stage process: build and install first, then test with kernel changes in play (not the case for ast) the ", then" above could even include unmounts reboots etc. I know that gnuish builds allow testing of uninstalled a.out's/.so's/dll's in the build "." but they have to stand on their heads with footool this and bartool that wrappers to get it right -- and after all that its *still* not testing the actual bits that eventually get installed this is especially true when parts of the build system itself are being rebuilt I also have to question using ksh93 as part of the current build/integration process that is essentially the ksh93 bootstrap the ksh93 part could fail and bring down the dependent parts with it or a goofy ksh93 bug/misfeature could creep into scripts in other parts of the build process (e.g., requiring script edits to fix the goofy bug/misfeature) it seems that the first step should be to get an independent, working, tested ksh93 installed -- after that the build can start rolling in ksh93 dependencies so lets do it as right as possible the first time, or the problems after mission accomplished will be much more time consuming -- Glenn Fowler -- AT&T Research, Florham Park NJ --
