> From: Andrej Falout [mailto:[EMAIL PROTECTED]]
> Problem is not in missed promises (except for CVS which is 
> just not going to 

The server cvs.sap.com is running and I got a port through the firewall to feed it 
from the inside, so CVS access to the current sources should be available at the end 
of the week.

> Apparently, it's a question of motivation. SAP AG wanted to 
> hurt Oracle, IBM, 
> Microsoft, as a way of saying "thanks" for stealing ERP 
> applications business 
> when selling databases for SAP R/3. And hurt them they will. 

The main motivation for SAP to buy and develop SAP DB was to have a licence free 
database with full control over the feature set. 
The main motivation to release it as Open Source was to make it better known such that 
SAP customers (who would get it anyway with some applications) would trust it.
We certainly weren't expecting to outsource our development. There are several reasons 
why we will probably never reap the benefits of a true collaborative development:
- tight control over features
- most discussions are held internally (because we're mostly all in one place) and it 
would be a lot of work to mirror them to mailing lists or such (and to translate 
everything to english)
- restrictions on compatibility between releases

But: surprise us.

> From: Richard Barrington [mailto:[EMAIL PROTECTED]]
> In that context, maybe it works to think of it like the Linux kernel
> model, with contributors providing many patches, but only the (
> benevilent-dictator | salary-paying-junta ) gets the say on what goes
> into the offically blessed code base... but there's nothing to stop
> anyone else patching their code as they see fit, if the resources are
> available.

vmake allows a development style to fork only individual modules. $VMAKE_PATH works 
similar to the VPATH variable:
VMAKE_PATH=/work/sapdb/projectx,/work/sapdb/official
where /work/sapdb/official would be updated from cvs.sap.com
and /work/sapdb/projectx would be updated from sapdb-featurex.sourceforge.net.

/work/sapdb/projectx would contain only changed sources and the members of projectx 
would work with normal sources instead of patches. Changes in the official tree are 
automatically seen unless it's in one of the changed modules. When some of the changes 
are integrated into the official sources,
then the corresponding source can be deleted from projectx.

Daniel Dittmar

-- 
Daniel Dittmar
SAP DB, SAP Labs Berlin
[EMAIL PROTECTED]
http://www.sapdb.org/
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to