oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Barber <tom.bar...@meteorite.bi>
Subject Re: OODT Roadmap Telecon: summary of the event
Date Thu, 07 Aug 2014 20:52:41 GMT
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, <kelly@apache.org> 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

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