Thanks Chris.,
On Mon, Aug 11, 2014 at 5:14 PM, Chris Mattmann <[email protected]> wrote: > 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 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* > > > -- *Lewis*
