We would be interested in helping. OSDL is chartered to provide Open Source developers with resources to build enhancements into Linux and it's Open Software Stack.
We can provide a Linux/Intel development platform, and large (1 -> 16 CPU ) machines for development. In addition, we have several database performance workloads which run with SAP DB which can be used to test patches and measure improvements. Best of all, it's free :) Our resources are tied to what we call Projects. Creating a Project is a simple one-page Web form. ( http://www.osdl.org/projects/project.html ) We've already talked to our management, and Project approval won't be a problem. I'll volunteer to help with the Web-paper work :) To move forward, we'd need this: - Someone to step forward and be the Project Co-ordinator. ( manage the list of project members, maintain communication. We'd prefer that the Co-ordinator be a non-OSDl person ) - project people need to be OSDL Associates. Again, it's free, a simple one page web-form. We have a current Sourceforge project for the performance test (http://sourceforge.net/projects/osdldbt) which also has a mailing list. We don't directly provide CVS ( we normally use Sourceforge ) but we'd certainly help admin a repository. We could use our test kit on a development machine to provide a 'nightly build' kinda environment if that sounds good. What do you all think? Any takers? cliffw > On Tue, 2002-09-24 at 12:16, Andrej Falout wrote: > > Maybe the temporary answer is to collect all patches provided by community. > > Anyone? > > Andrej, > > This could be a good thing. It would allow the SAP folks to utilise > those patches which are deemed appropriate for their environment, while > still maintaining access to fixes/features/bugs for the rest of us. > > 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. > > Most people will still use the offical code, but some will try the other > stuff out. If feedback can be captured through lists or forums, we can > all know what works for better or worse, and everyone can benefit. Also, > if the "alternative" patches work better, are more portable, and end up > becoming a fork, so be it - it'll only happen if there's a need. > > And yeah, I agree we could look at the Firebird model... (having said > that, I know of local businesses using it to keep costs down for > clients) > > Richard. > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
