Re: Adjusting to DB2

Serge Rielau wrote:

>
> I suppose the reasons cannot be confirmed by either of us and Mark T.
> silence may be interpreted either way.

Not silent - I just don't read the newsgroups on Oracle's dime, so it's always an extra circula activity for me

> If Oracle lumps QA and ID into their porting division that would be a
> surprising organization to me though.

The porting teams at Oracle do indeed do their own QA. They also do their own install docs. If you look at the number of products supported on the number of platforms, it works out to about 2.8 heads per product per platform. Not really alot. I'm sure the DB2 LUW team has more than 2.8 Sun or HP engineers involved in their ports.

> When did O10gR2 ship first btw? If I were a Windows shop and had to wait
> for sevaral months compared to Linux or Sun I would ask questions.

Linux was July, other Unix variants August, Windows September. Other platforms are still coming out.

The reasons for the lag are very simple. We run massive regression tests before we release (and also during development), on huge grids of machines (some 1400 CPUs or more).

The hardware used for these tests are centralized and shared by all the server tech product teams - so that's database, app server, grid control, collab suite etc. So in DB2 land, that would be like all the DB2 dev groups sharing the servers with the WepSphere group and the Tivoli group as well.

So it's simply a scheduling issue - sometimes the port of one product has to stand by while a different product gets it's share of hardware.

It also takes quite awhile longer to run the regressions on Windows than it does on Linux/Unix. Go figure

> The reasons you bring forward are about human resource allocation. It
> speaks to me about commitment.
> A product that uses good encapsulation does not require the same amount
> of QA across all combinations of platforms because only low level
> function can diverge.

We would disagree. 27 years of supporting every platform under the sun (no pun intended) has taught us that this is a very, very dangerous assumption to make. Even the compilers on different platforms can do vastly different things with the same code line. And not to pour too much gas on the fire, but I think Oracle development has a great deal more experience in supporting a single code line on multiple platforms than the DB2 LUW developers do.

> A product that uses good encapsulation does not require extensively
> customized documentation per platform. If I need to learn a different
> set of docs for a different platform that does not speak well for
> portability. The platform differences for DB2 for LUW are so small that
> they fit into paragraphs at the appropriate manuals (like setting up a
> c-compiler or where digianostics are dumped, ...).

Same for Oracle - typically just the install guides and release notes differ from platform to platform

> I do not know how well Oracle's codebase is encapsulating the OS APIs,
> but your arguments, if true, are not disarming the correlation.
> Deep exploitation of OS across major code segments (such as RAC) is very
> expensive to support and now we are really not talking same codebase
> anymore are we? Which is the haggling point of this subthread.

The code line for RAC is the same on all the platforms. Just the OSDs (what you call the OSSs) differ. Received on Wed Oct 26 2005 - 20:27:37 CDT