Well the machines would be for development testing. Not so much day to day development as that would be everybody's local machine. :-)
On Wed, 2002-09-25 at 09:59, Cliff White wrote: > 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 -- Timothy D. Witham - Lab Director - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 15275 SW Koll Parkway - Suite H - Beaverton OR, 97006 (503)-626-2455 x11 (office) (503)-702-2871 (cell) (503)-626-2436 (fax) _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
