Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS »
Discussion: OpenMRS Talk »
Real-Time: IRC Chat

Resources

Skip to end of metadata
Go to start of metadata

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