Page History

...

•  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. UPDATE: As of Jenkins  build #1438 08-Aug-2014 19:25:25, the codebase is again stable. It should however be noted that there are some tests which fail intermittently as it would appear they are perhaps environment specific. These should be addressed as separate issues if and when there is motivation to do so.
•  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".
•  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.
•  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.
•  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.
•  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.
•  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.
•  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.
•  Where and what are the extension points?  This needs to be clearly documented and highlighted.
•  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.
•  Put Jenkins build status on the OODT website!
•  Videos (screencasts).  But keep them upbeat.  Edit them carefully so users aren't watching slow typists backspacing over mistakes repeatedly.
•  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.
•  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.

In addition to the above, following improvements have been decided to make on OODT based on discussions had in mailing lists and slack channels over the past years.

•  Consolidate logging in OODT components OODT-693.
  
•  OODT-986 A new UI for OPSUI - Hopefully a more reactive and responsive UI which facilitates from a REST API.
•  Finalize AvroRPC changes. This is already done, but requires to be validated in Resource Manager
•  
  

For more information please look at the child pages in the left sidebar.