Thanks Guys. I'm trying to help stabilize the CAS components in particular for CAS-PGE to get it working in trunk again so folks don't use a 0.3 PGE container in workflow.
The other thing I'm working on finishing OODT-491 (wengine), and also more Tika integration wherever possible. Finally, Resource Manager is broke and needs a fixin. That, and RADIX/Vagrant for easy up and sensible defaults. Sorry I wasn't able to make the call I had a summer student giving her final presentation that I had to attend. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Lewis John Mcgibbney <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, August 7, 2014 1:47 PM To: "[email protected]" <[email protected]> Subject: Re: OODT Roadmap Telecon: summary of the event >Next step... >Volunteering to take actions. >Thank you Sean for posting, thisis extremely helpful. >Lewis > > >On Thu, Aug 7, 2014 at 1:44 PM, <[email protected]> wrote: > >> Folks: >> >> Thanks for dialing into the OODT Roadmap Telecon. >> >> The attendees were: >> >> - Tom Barber, UK business intelligence consultant >> - Roger Carter, JPL intern >> - Cameron Goodale, JPL >> - Michael Joyce, JPL >> - Sean Kelly, consultant >> - Ross Laidlaw, JPL intern >> - Lewis John McGibbney, JPL >> - Tyler Palsulich, JPL intern >> - Rishi Verma, JPL >> >> >> Here are the milestones that I recorded from the telecon, presented in >>no >> particular order: >> >> A. Stability to the codebase. Tests must pass before we can reliably >>move >> forward. This is especially troublesome since there are new features >>we do >> want to implement, yet our confidence level of not breaking existing >> function is low since the tests just don't work. >> >> B. Upgrade OODT's outdated components. A number of parts within OODT >>has >> ossified and become brittle (XML parsing, for example). As the (mainly >> Java) ecosystem has matured, these components have not, and they >>continue >> to be "software hangnails". >> >> C. End-to-end story-driven testing. While we'd love to see more and >>more >> unit testing, complete integration testing is also vital. OODT is a >>large >> and complex system, and ensuring all the parts work in a story-driven >> manner is important. >> >> D. Changing 5 to 10 config files to get OODT just to work is terrible. >> And worse, they're largely XML configuration files. OODT needs to >> get-up-and-go out-of-the-box. >> >> E. Documentation and website movement to Apache CMS-based tech. The >> static nature of the OODT website is a barrier to updates. We'd like >>for >> updates to frequent and timely. >> >> F. Make OODT more of a product, less of an architecture. It's difficult >> for new users to approach OODT since it's presented mainly as a software >> architecture that has some software. If we could change it into a >>product >> (by providing sensible defaults, IoC, etc.) it could have a lower >>barrier >> of entry. >> >> G. Remove PHP. OODT requires a Java servlet container for its core >> function, so why bring in yet another technology for the Balance >> components? This increases the exploitable surface of an OODT server as >> well as making adoption of OODT trickier. >> >> H. XML specification and/or schema so you can know what can be where. >>For >> these XML configuration files, the lack of a schema means it's >>difficult to >> tell what elements and attributes go where, which are required, which >>are >> optional, etc. With a schema (and an XML-aware editor) this becomes >>easier >> to do‹and gives validation-before-run as a bonus. >> >> I. Where and what are the extension points? This needs to be clearly >> documented and highlighted. >> >> J. Tutorials are static and don't allow for community updates. We need >> them on the wiki instead so everyone can help. Leave a "getting >>started" >> tutorial on the main website, but move everything else to the Apache >> Confluence wiki. >> >> K. Put Jenkins build status on the OODT website! >> >> L. Videos (screencasts). But keep them upbeat. Edit them carefully so >> users aren't watching slow typists backspacing over mistakes repeatedly. >> >> M. Regular release cycle. Four times a year. This gives "liveness" to >> the project, but also gives confidence to new users knowing that a >>certain >> bug or new feature will be addressed in an upcoming release. >> >> O. Report list subscription numbers in board reports, not # of messages. >> This is a more interesting metric since it demonstrates the breadth of >> OODT adoption, which is orthogonal to the amount of discussion which >>can be >> dominated by one or two members. >> >> What milestones did I miss? Do these sound correct? Please reply to >>the >> list and let's discuss further. Once we've hammered out this list, we >> should then priortize them. >> >> Thanks again for your participation, >> --k >> >> -- >> Sean Kelly >> Vice President, Apache OODT >> Member, Apache Software Foundation >> >> > > >-- >*Lewis*
