/
Current State Technical Evaluation (TECH)

Current State Technical Evaluation (TECH)

Description:  Review current code assets including features and technical debt 


Leads: Rich, Ashraf


Rapporteur/Notetaker:  Darius

Notes from Session:  (audio recording failed)

Intro

  • Key Question:  "What should the next implementation do?  Which branch does it start from?"

Currently:

  • "2.0" is pulling from "eLMIS" automatically, at every commit
  • "eLMIS" has pulled from "2.0" once (very recently) and intends to continue doing this manually ~ every week
  • "2.0" is a "development trunk", it's not typically fully functional

 

Karl: I'd like to see over the next 6 months, that "2.0" becomes the master upstream branch for development. And having the "eLMIS" in bitbucket makes things a lot harder.

 

Rich: Right now, 2.0 is not really "upstream", and we all want it to be.

 

Ashram: Once VIMS is released (later this year, or next year) then we can put resources into shifting from bitbucket to github.

 

Rich: Current state: 2.0 is not releasable (e.g includes incomplete features)

 

Karl: Have a separate repository with Moz-specific configuration. Going forwards, we should have a default/demo configuration and feature toggles that disable features not yet complete.

 ---------------

New features in 2.0 (Ashram)

 

* Different configurations for R&R, with different calculations ("R&R Templates")

* Different groupings within an R&R

* Reports

* Checks status of equipment before certain orders (and requires explanations for broken equipment)

* Dashboard on home screen (role-specific)

* uploading of photos from an android application (ODK)

* integration with RapidSMS gateway

* GIS map

* ILS gateway

 

------- 

Some Code Statistics (Josh)

  • 68k lines of code
    • core: 12k LOC
    • reports: 12k LOC
    • openlmis-web: 5.6k LOC
    • vaccine: 3k LOC

            

  • including tests, ~100k lines of code
  • total test coverage: ~25%
  • ~200 DB tables

             (Ashram: some database tables are there as proof of concept and are great examples of things to "clean up")

What we need to make a master branch?

  • Cleanup:  remove tables
  • Hide features (UI)
    • Doc/describe how
  • Have a default/demo config (following github.com/clintonhealthaccess/lmis-moz pattern)

    • Evaluate TW customization module

    • For country-specific configurations
    • Doc and recommend as good practices
  • Doc and describe features
    • Identify which are Global versus country-specific
  • Merge in "accessibility"
  • Published FAQ on current state?
  • Endgame:  final test/stability run; merge to master
  • Finalized branching strategy (e.g. "gitflow")

Related content

Evolving to new development practices (TECH)
Evolving to new development practices (TECH)
More like this
2.0 Release Project
2.0 Release Project
More like this
2016-02-23 Meeting notes
2016-02-23 Meeting notes
More like this
Collaborative Development Mechanisms (TECH)
Collaborative Development Mechanisms (TECH)
More like this
Technical Committee Sessions Read-Outs/Group Discussion (Plenary)
Technical Committee Sessions Read-Outs/Group Discussion (Plenary)
More like this
Re-Architecture Feedback responses
Re-Architecture Feedback responses
More like this

OpenLMIS: the global initiative for powerful LMIS software