Lewis you now have access thanks ------------------------ Chris Mattmann [email protected]
-----Original Message----- From: Lewis John Mcgibbney <[email protected]> Reply-To: <[email protected]> Date: Monday, August 11, 2014 5:08 PM To: "[email protected]" <[email protected]> Subject: Re: OODT Roadmap Telecon: summary of the event >Hi Folks, >Can someone please add these to the Wiki Page Tom created? >I have to request access to the wiki as I don;t have write access. >Can oneone do that for me here or do I need to go to #asfinfra? >Thanks >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 doand 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*
