Date: Tue, 26 Sep 1995 18:46:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org Subject: Re: ports startup scripts Message-ID: <199509270146.SAA09152@phaeton.artisoft.com> In-Reply-To: <24295.812164359@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 06:12:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The product is QA'd with the validation suite. 2 hours were required for > > the validation suite, which is interesting, considering POSIX validation > > takes less time to run. > > Sorry, this statement simply leads me to believe that you've never > worked on anything of significant size or complexity. 2 hours is > about how long it took to brief the QA team on how to structure the > run at most large ISVs I've worked at! :-) If you got the results back > in 3 or 4 days you considered it a rush job. I worked on NetWare for UNIX... it was 3.6 million lines of code. Does that count? How about SVR4.2 ES/MP? Of course, it was only portable to an SVID/POSIX/ANSI environment. I agree that it couldn't be ported easily. On the other hand, Lotus 1-2-3 is not rocket science. Neither is the application level product I've been using as an example. If you don't automate your Q/A process, I can see where it might take humans a long time to validate it. And yes, it takes work to do this, but overall less man hours than you would spend for 3 or more ports to have humans do what the machine should be doing. > Plus it's an on-going thing. You need to re-QA on *every* point > release you might make for that platform. No argument here. > You ever worked in a Crosby method "zero defects" shop? There are > *procedures* for all this stuff and checklists to be followed. Like branch path anaylisis and full code coverage in the validation suite? That's the correct way to automate testing/validation. > I don't care how bloody well written the software was, in a lot of > cases this is simply *not* a technical problem! It's a problem of > "1 platform = 1 overall pain in the butt, always" I always thought it scaled like SMP: the more platforms you add only fractionally increase the problem load. 8-). > Multiply this by 6 and you're lucky if you can sit down. No holy > grail of software design will save you from going through regression > tests as complex as certain types of SDI targetting software, to say > nothing of the paperwork. Sorry. If the code passes regression tests on one platform, you are testing either the compiler or the C libraries if you perform full regression on subsequent platforms. Part of the validation is a branch path test of the libraries do that you know all your uses are covered. A regression test is still useful at this point only if fixing the platform is an option (or if simply not shipping is an option). I have a lot of respect for Lotus's quality -- the best quality, bar none, of a first release. I have no doubt with what you've said about "who owns the problem" that not shipping was an option. I think that's where we diverge. > > You also presuppose an idea world where I have the *choice* of writing > god's gift to portable code and aren't simply stuck with porting a > large legacy application to all these new platforms. The times where > I actually got to write a major shelf application from scratch and > according to my standards can be counted on the fingers of a penguin! 8-). A port is an opportunity for rewrite if your management isn't screwed and the code isn't going to end up as a collection of patches. Again, this is only an option if your portability changes get rolled back into the main line code. Porting a legacy app is not a situation where this happens, since any additional developement on the legacy code is throw-away. But then you are already setting yourself up for failure, since any platform being ported to is a second class citizen. This is a political problem, and one can not draw valid conclusions about platforms from the internal politics of a company. One can only draw conclusions about that particular companies opinion of the platform. > Usually the scenario is that the Windows weenies get to write it as a > Windows app because they only represent about 500 times the revenue > you do and the 500 pound gorilla gets to sleep wherever he wants, > and you're stuck trying to port it to UNIX. WABI? Don't make me laugh > until tears run down my face. >From this argument, one would conclude that the only successful DOS programs are those that were ported from CP/M, since at one time CP/M was wildly more popular than DOS. 8-). It's perfectly valid to not endanger your mainline product for a port. The point is that you are not allowed to make overall design tradeoffs that would penalize a windows version. That does *not* equate with *requiring* a paritcular design, antithetical to portability in general and antithetical to UNIX in particular. Again, we are talking internal company politics: whether you can replace "Mr. Golden Boy"'s code with functionally equivalent but architecturally more portable code, or not. The problem is in the interpretation of "change" as "danger" by people who aren't engineers. All of which speaks to the viability of a particular companies ported product on a given platform, not to the viability of the platform. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509270146.SAA09152>