Date

23 April 2009

In Attendance

• Mike Seaton

• Ben Wolfe

• Darius Jazayeri

• Burke Mamlin

• Justin Miranda
  <!--

• Paul Biondich

• Brian McKown
  -->

Agenda

• OpenMRS 1.5 alpha needs to be released. Release Manager volunteers? -Ben 10:23, 20 April 2009 (EDT)

• Discussion about modules - need new features for modules (some rough thoughts outlined below)

  • Move towards a Linux/Eclipse idea of thin kernel + lots of modules with complex dependencies

    • i.e. OSGI implementation of module framework

  • Need to move all non-patient related components into Core Modules

    • Some modules that should be included as Core Modules ...

    • Scheduler API

    • Reporting API

    • Form API

    • (there are others – just can't think of them at the moment)

  • We can then build modules that are based off Core Modules and have their own roadmap/versioning

  • Requires a more strict versioning and dependency

  • Need to support plugins for API components that are not patient-related

  • Need to add more separation between core API and implementation/tool modules (i.e. simple web)

  • Need to support module bundles

    • Allows us to create a reporting module bundle that holds multiple modules that work together

    • Allows us to install and start a bunch of modules together

    • Allows us to add/remove modules together

    • Keeps implementers from having to choose modules that are compatible

  • Modules need upper version dependency (works with OpenMRS 1.4.7+, but not 1.5.0+)

  • Module IDs should be fully qualified package (like Eclipse)

  • Move old reporting to a Core Module

    • Need to consider using this module as a library within trunk/lib

Minutes

• 1.5 Alpha release?

  • the alpha doesn't need to be feature-complete. aka, 1.5.x doesn't need to be created

  • We need to create a recipe for testing the web. pih/sync has a google doc to keep track

    • The google doc just has a list of things to test. if it fails before a release, the error message or a red x is placed (manually) into the google doc.

    • We don't need to spend hours coming up with tests. But we do need to figure out.

    • TODO: Darius copy pih google doc over to public place and link to from

  • release manager: Ben

  • (Justin volunteers to be release manager for 1.6)

  • Do we need to pass through the tickets and assign everything to 1.5/1.6/someday?

  • We need to look at Jira's Jira to see how its "supposed" to be done. (or trac's trac?)

• Modules

  • Background: Justin/Mike are working on reporting and see things in core that really aren't core to an MRS. (Things like form/cohort/reporting/etc)

    • Started adding module dependencies and seeing weaknesses in our module framework

  • Changing core to a more a modular based framework would facilitate coding faster and getting releases out easier, less coordination of code, etc

  • Modules still need to be fairly easy to write so that all the work isn't going into writing a module's shell and not code

  • Reporting: Mike has taken most of reporting packages out to a module.

  • Reporting: CohortDefinition has been removed, Cohort has remained

  • Scheduler API: can be pulled out easily.

  • Reporting: Do we want to pull out everything and just point people at the module? deprecate things for a version as much as we can?

  • Reporting: Deprecate all reporting methods for 1.5. Delete web layer links, pages, controllers for reporting. Create reporting-1.0 to be included with 1.5 as a core module. For openmrs-1.6 move reporting objects/methods into reporting module and delete methods from core.

  • Reporting: TODO: Mike will deprecate reporting methods in trunk before 1.5 release.

  • OSGI: we don't need to switch to it right now.

  • OSGI: Ben: From what I've read, osgi is above tomcat and you include that as a plugin within it.

  • OSGI: TODO: Justin will read more about osgi

  • OSGI: TODO: Paul will reach out to some people that have osgi experience (phillipe, kayolan, etc)

  • TODO Ben: create a ticket to add an upper bound for version's required by a module