Hi Everyone,
Together with Soldevelo team (@pgesek, @pkornowski, @alalo, @dserkowski), we would like to invite you for first sprint review. Details of the event are stated below:
(If the time is not convenient for you, we can try to find better one.)
Did you add this to the OpenMRS calendar?
I don’t have permission yet. I asked for access to add events to this calendar today.
@pkornowski / @dkayiwa is this happening now? I tried connecting to the hangout but wasn’t able to get in. Have others been able to join? I believe @cioan also could not connect.
Thanks, Mike
@pkornowski because 2pm varies depending on which time zone, it would also help to say something like “in the next xxx minutes or hours” 
Sorry, it will be in the next 20 minutes
At first i was denied access. But now am in.
Okay, great. I think it was missclick
Thanks all,
I will try to connect. Seems like a classic case of timezones and daylight savings time causing havoc. Above, in the original post, this is what was listed:
I believe that was the last hour?
Best, Mike
No, meeting started 5 minutes ago. Would like to join?
Referring to the conversation above and in the meeting. It was a misunderstanding with timezones. Next time I’ll pay more attention to that. I will create a reminder on the Talk 10-15 minutes before meetings.
Attendees:
Meeting minutes:
If you didn’t attend the review meeting you can watch this below this link: https://www.youtube.com/watch?v=nJjYuSus1gM
cc: @jslawinski @pgesek @dkayiwa @mseaton @alalo @dserkowski @cioan @raff @nagadya
@pkornowski Are there any conclusions regarding OpenMRS versions that we want/have to support? This looks like a very important question that should be answered rather sooner than later. @mseaton Any thoughts?
I will do research tomorrow about how much it will increase the effort for the project. The conclusions will be shared here. I concern about the differences between domain classes.
@jslawinski, regarding the OpenMRS versions to support, I don’t have a hard and fast answer to this. I do know that the sync 1.0 module was originally designed for PIH in Rwanda, and has been running there at scale for over 10 years. We would love to explore migrating to the new sync module there, but this system is currently at OpenMRS 1.9. We hope and expect to upgrade to a more recent version at some point, but have been unable to move this ahead for a variety of reasons and the timeline is uncertain. Many implementations that have been running for many years will have similar issues, particularly if the system has been deployed nationally at scale.
While it might be a lot to ask to support versions back to 1.9, I do think that this has benefits - for example, it will force us to ensure that sync 2.0 can support and handle and evolving OpenMRS core versions over time. It is inevitable that changes to core domain objects will happen in future versions, and by building this assumption in from the beginning we will add more resiliency to the module.
Overall, I’d ask what we think the burden will be for supporting older versions of core, and what technical limitations prevent it. Based on the answer to these questions, we can make a determination as to what to do. If we limit this module to OpenMRS 2.0+, we will have considerably fewer implementations that will be in a position to test and benefit from this module.
Best, Mike
Personally I vote for requiring Platform version 2.0.x+, because we did various major refactorings there, and I assume it will lead to more straightforward and cleaner sync code to not have to code around this.
(Mike asks a good question about what will be the actual impact of this…)
I personally feel that if we require platform 2.x, then it may never be used by any implementation for a year or two. I do not think these developers will be happy having done modules that no one uses for quite some long time. In other words, those anxiously waiting to use the modules are still running 1.x
@dkayiwa, Bahmni and most RA implementations should be running core 2.0.x+ already so I wouldn’t be so pessimistic, when it comes to finding first users, if only supporting core 2.0.x+.
Yet, I feel SolDevelo should base the decision on partnering with an org, who wants to use it the moment it is ready and PIH seems to be interested in deploying for 1.9.x. In the first pass I would aim to develop for the exact version you want to use it with first.
It feels that extending Sync 2.0 to support other versions of OpenMRS would be a similar effort now and after implementing it first for a specific version assuming we have solid integration tests, which can be run against different OpenMRS versions and considering some major differences now.
If you intend to use webservices.rest and fhir modules then they support 1.9.x+ and 2.0.x+ accordingly so at least fhir would have to be adjusted for older versions.
We also upgraded Hibernate in core 2.0.x, so you will need to handle small differences, if you are working at that level to discover updated objects.
There’s also a matter of UI difference. The older implementations most likely use legacy UI (jsp), whereas newer implementations use UI framework (gsp). That, however, could be easily handled by implementing UI as OWA, which should work regardless of the core version.