[OPEN-ILS-DEV] Planning for Evergreen development, post 2.0

[Dan Scott]

A few developer meetings ago
(http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2011-01-04)
, I threw out a couple of ideas about Evergreen development tasks that I
thought we should start considering once 2.0 wraps up. We decided to
brainstorm these on the mailing list, and so here's an email to kick
things off. I'd suggest that if you want to discuss one of the ideas in
depth, that you reply and change the subject to create a new thread; if
you want to add another idea, just reply to this message and keep it in
the thread (then detailed responses to those could go in new threads).
And of course we have limited resources, so there's no way we'll be able
to tackle everything, and at some point we'll have to prioritize. At
this point, though, I would suggest we brainstorm as much as possible
and then worry about reality :)

So here goes with some starter ideas:

  * Upgrade our Dojo toolkit usage to move from Dojo 1.3 to Dojo 1.5 

    Why: Better support for current browsers, more features, new Dojo
    documentation and blog posts will be more relevant, any bug reports
    we generate are more likely to be addressed (we're already
    working around one problem in 1.3 that was fixed in 1.5 per Galen)
    ...

    Development impact: Lots of UI re-testing. I think we're still using
    old-style grids (?), so a fair amount of code will need to be touched

    User impact: It seems likely that newer versions of Dojo will offer
    better performance / less glitchy painting / scrolling (but no
    guarantees for what we use). Accessibility support is greatly
    improved in current Dojo versions.

  * Move to git or some other DVCS for the official repository?

    Why: A number of sites (Sitka included) already clone the SVN
    repo into a local git repo to track their customizations. Launchpad
    clones our SVN repo into bzr to track translations and development
    series. We're living in a DVCS world, we might as well embrace it.

    Development impact: We would need to establish new processes for
    what goes into the canonical project repository and how it gets in
    there. We would need to migrate from SVN to a new DVCS and provide
    equivalent Web interface / commit mailing list / ? as the current
    Trac & commit hooks does. What happens to ILS-Contrib?
    
    User impact: Arguably none - unless you consider individual
    sites that maintain their own clones as users, in which case they
    run into less trickery running *-svn and dealing with conflicts.

    Discussion: Somewhat underway already at http://markmail.org/message/gtnc4bdfv3ub4mbm

  * Move to require a minimum of PostgreSQL 9.0 (raised by Mike
    Rylander)

    Why: Mike has some mysterious enhancements that would be much easier
    to implement if support does not also have to be provided for
    PostgreSQL releases prior to 9.0. See also generally claimed
    benefits of newer releases of underlying infrastructure, like better
    performance and fewer bugs.

    Development impact: Developers, testers, sites would need to install
    PostgreSQL 9.0 on their dev machines and servers. As no
    distributions currently offer PostgreSQL 9.0, they will have to
    install it either via distro backports or from source.

    User impact: The mysterious enhancements should arrive faster.
  
  * Provide a full-featured OPAC that requires no JavaScript, but uses
    JavaScript for enhancements

    Why: The current OPAC takes an agonizing amount of time to load when
    the JavaScript is not cached: 10 - 15 seconds on a DSL connection is
    pretty normal http://www.useit.com/alertbox/response-times.html has
    some interesting observations on Web response times, but we all know
    that 10 seconds is not fast. The underlying HTML of the current OPAC
    is also useless to Google and other search engines; a rewrite that
    generated semantically meaningful HTML could actually provide
    another entry point into our catalogues.

    Development impact: Another OPAC rewrite. Would it be possible to
    provide the functionality we need to support the staff client in the
    new OPAC in the time frame we have to develop a new HTML-based OPAC,
    or would we have to maintain both OPACs for a period of time? (The
    latter seems likely anyway given the investment in skins that some
    sites have already made). Skinning will require learning TT2 or
    whatever underlying framework is chosen (which might be easier/more
    powerful in any case).

    User impact: Changed user interface means some relearning. Speed
    boost should be significant.