2009-04-02 Developers Conference Call

Owned by Former user (Deleted)
Last updated: Aug 18, 2010Version comment
3 min read

Date

2 April 2009

In Attendance

  • Mike Seaton
  • Ben Wolfe
  • Brian McKown
  • Darius Jazayeri
  • Burke Mamlin
  • Justin Miranda
    <!--
  • Paul Biondich
  • Sam Mbugua
    -->

Agenda

  • GSoC
  • Discuss strategy for reporting (Justin)
  • Open SVN branching and/or creating a sandbox in svn for people to play with? -Ben 10:45, 1 April 2009 (EDT)
  • If time permits, otherwise move to next week:

Minutes

  • GSoC
    • Applications are due tomorrow
    • We might extend OIP one extra week to get more proposals for that
    • Tell students to submit now and they can revise after submission.
  • Strategy for Reporting
    • Justin/Mike will do planning meeting today
    • Justin will add reporting timeline google doc and share with everyone
  • Deprecating Reporting packages or deleting them?
    • Brian: Leave old tables and data so that backwards movement is possible
    • Justin: package naming, etc was poor and can't easily be forwarded
    • Mike: Do it on a case-by-case basis. ie look at data exports vs report_schema_xml
    • Darius: CohortDefinition vs PatientSearch implements CohortDefinition vs new CohortDefinition in different package. Do we need to support these in the API, or just convert the objects
    • Mike: migrate data out of report_object to serialization_object. maybe leave the report_object table so people can roll back easily?
    • Burke: be mindful of people needing to roll back as soon after they try to upgrade. in 1.6 remove the table
    • Mike: there is a different between data loss and API objects being removed
    • Mike:
    • Burke:
    • Mike: Supporting deprecation for all reporting objects is taking a really long time.
    • Darius: The reporting stuff wasn't really used at all
    • Ben: Use google to search for uses: Parameter site:dev.openmrs.org/browse/openmrs-modules
    • Burke: This is an exception to the 'deprecation' rule because it isn't really used by anyone
    • Mike: I'll try to be doing it in pieces. Cohort, then parameters, then report, etc. Each code review can then identify pieces that should stay or get the boot
  • SVN sandbox?
    • Darius/Burke: people should email code@openmrs before creating the branch
    • Ben: The email to code is useless and not needed and prevents people from putting up branches
    • Burke: The community needs to know about the branches and should be notified
    • Mike: "code@openmrs is not the community"
    • Darius: modules are different and should always get an email from the developer before starting
    • Burke: is that true for non "core" developers ?
    • Darius: If you aren't sure if you create a branch, you should be asking
    • Ben: if they have commit rights they should be able to commit
    • Burke: (relenting) full committers should be able to commit and if they are doing something dumb an email tot he dev list should chastise them. The commit message should say about why. an email to the dev list should happen automatically. non full committers should "ok" it with a full committer and should put hte full committer's username into the message so that the dev list knows.
    • Brian: We need a convention police pseudoname so that not one person has to be the evil one that is holding people to it
    • Mike: a partial committer should be able to create a branch that is associated with a ticket. a partial committer could create a branch with a message
    • Darius: who is a partial committer?
    • Burke: anyone who has a trac account AND has asked code@openmrs for write access.
    • Brian: where are the conventions?
    • Burke: we should email the dev list about the new conventions
    • TODO: make adjustments to the conventions page about branch creation (full committers are free to do it and commit comment should be descriptive, partial committers need to talk to a full committer first and have a descriptive comment + full committer username)
    • TODO: create svn hook to email dev list if a new branch is created
    • code@openmrs stays around for asking about modules
    • Ben: "entropy is inevitable"
  • Guid work
    • Darius: we're going to add in the guid stuff
    • Its going to be called uuid instead of guid
    • all domain objects are going to extend baseopenmrsdata or base openmrsmetadata
  • handlers
    • mike found a magic spring way to use annotations to register handlers instead of using the xml we're doing now
    • see archive:TRAC-1386@ticket
    • Darius: is it ok to have ServiceContext extend Spring's ApplicationContextAware ? It makes spring a really strong dependency
    • Burke/Ben: spring is already bundled tightly so it shouldn't matter
    • Mike: I want this reviewed on Monday, Damn it! ("damn it" inferred by note taker)