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