Thanks Sean - this is great. I'd suggest each of us get into JIRA and just make issues where appropriate. Some already have been logged (i.e. website work).
Second, let's set a release date for 0.7 so we have a timeline to move forward with. We've almost got FM tests fixed and we now have an easier RADiX and Vagrant box for new users, so I'd suggest September 1st may be a good target (and every three months after that). Thoughts? Thanks, Rishi On Aug 7, 2014, at 1:52 PM, Tom Barber wrote: > Volunteers are useful, but also breaking the issues down into chunks and > prioritizing the various tasks as well > > Tom > > On 07/08/14 21:47, Lewis John Mcgibbney wrote: >> 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 >>> >>> >> > > > -- > *Tom Barber* | Technical Director > > meteorite bi > *T:* +44 20 8133 3730 > *W:* www.meteorite.bi | *Skype:* meteorite.consulting > *A:* Surrey Technology Centre, Surrey Research Park, Guildford, GU2 7YG, UK
