+1 post away :) (ok, so Steve, you have access to actually post the report to the wiki... ? think I got it now..)
-----Original Message----- From: drtobes [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 8:09 AM To: [email protected] Subject: Re: [Fwd: WARNING - 2 days to deadline for May reports] On 5/8/07, DeBardeleben, Ruth L <[EMAIL PROTECTED]> wrote: > so Bill, do you have what you need for the board report? Are we done? You mean Steve, or you for that matter. Bill is here to make sure we follow the rules and provide guidance with issues, primarily. That being said I think we're about done, here's the report I have gathered from this chain: ################################## Several members of the Lokahi community attended Apachecon EU in an effort to grow the community. A FastFeather track on what Lokahi does and what it currently supports (slides are available here: http://people.apache.org/~toback/presentations/Lokahi-fast-feather-05-04 -2007.pdf ). Specific outreach was made to the Geronimo community to help us get a sense of what it would take to have Lokahi control the Geronimo stack. A significant number of committers from other projects have subscribed to lokahi-dev over ApacheCon after discovering how this project could solve their own infrastructure headaches or how it could be enhanced to support their project's configuration and management. An initial roadmap of features has been planned, and development will be moving in the direction of the new roadmap. An initial draft of Lokahi's data model for the proposed switch to a Jackrabbit back-end was worked out with input from Jackrabbit community. The conversion to JCR takes first priority because it will mitigate existing difficulties that hinder community-growing, namely: (a) Oracle as db requirement, which reduces the potential user "market"; (b) inability to run Lokahi on a standalone machine, due to (a); (c) complicated build process, partially due to (a); JCR will provide the following benefits: (a) database independence (run Lokahi with a file system backend to try it out, or use a more robust storage platform for production) + embedded Derby db (b) lower barrier to contribution, see (a) (c) versioned objects -- the basis for storing versioned configuration files & foundation for a future "undo" feature requested by users. Great for real-world use in regulated environments which require detailed audit trails of who-changed-what-and-when. Obstacles to graduation: * community - now includes authors outside of the original dev community, but additional committers are sought. Recent distractions reinforced the fact that a larger committer base is needed to graduate. * licensing - oracle-only backend is now 90% of the way to an alternate MySQL backend, and soon to be enhanced with license agnostic interfaces ############################ I will post this later today if no one has any objections. Steve ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------
