[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtm-perl
Subject:    Seen Bhaskar
From:       Emiliano <emile () iris-advies ! com>
Date:       2001-01-12 14:22:42
[Download RAW message or body]

Hi guys,

I just had a meet with Bhaskar. Nice person.

We've talked a bit about the release, the work we as a group are doing,
and transactions.

Concerning transactions, he surpised me with the way GT.M does
transaction
restarts. Yes yes, I know this is old stuff for you but I haven't
actually
seen this done in this way in any database environment before. Mundo
cool,
and it's going to be interesting to implement this outside of Mumps (any
chinese around?).

The release is awaiting three things: review of the license (they'll use
the GPL but they're going over it for their own peace of mind), a sane
build system someone outside of Sanchez can use, and a CVS checkin
policy.

Oh wait there's a little more to the license: they're looking for way
to make sure that they can use the submitted patches in their
proprietary
version of GT.M, in order to maintain compatibility. The 'linux' version
stays OSS.

The CVS checkin policy is going to be good. Basically, only Sanchez
engineers
get CVS access to sourceforge; patches will be accepted but will be
subject
to code review and regression tests at Sanchez before checkin by their
hands.
The regression tests are something else: a 2x800Mhz system with 'a
couple of'
gigabytes of ram runs for 16 hours to complete. Don't try this at home.

They're open to offering a lot of help, including the creation of the
DAL
for us, but not short-term. They're thinking some 6-8 months, maybe
longer.
If we manage before it goes to the hoops described above.

I'll be plugging away at a better build system, possibly beating them to
release; they know about this and are proceeding their own way (with
communication back and forth) with the makefiles that actually only set
up
a good environment to call the multitude of scripts that actually build
the sources. I am working on a 'normal' autoconf/automake system.

Bhaskar is going to see to it that the phrase 'open source for Linux' is
changed or explained. What it comes down to is that the sources as me
and
Tom have them are going to be released. Any x86 unix platform (or wintel
using the cygnus toolkit) should be a relatively easy port. Non-x86 is
going to be a major effort. Bhaskar confirmed that 'open source for
Linux'
actually means, 'Open Source, compiles on Linux, good luck on other
platforms', which works for me. Having an autoconf/automake environment
should make 'porting' easier.

Emile

[prev in list] [next in list] [prev in thread] [next in thread]