+1 To September 1st and at least every 3 months after. Also, make sure to label issues as blocker. That way, we'll know exactly what issues need to be resolved and when.
Tyler On Aug 7, 2014 3:45 PM, "Verma, Rishi (398J)" <[email protected]> wrote: > 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 > >
