oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ke...@apache.org
Subject OODT Roadmap Telecon: summary of the event
Date Thu, 07 Aug 2014 20:44:06 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message