Date
Attendees
Apologies
Goals
- Review Actions
- Discuss next weeks tasks
Discussion items
| Item | Who | Notes |
|---|---|---|
| UKRDC-TNG Version Control |
| |
| OPT out on UKRR data | Tim Whitlock (Deactivated) | There is a field called something like UKRR_OPT_OUT on the PATIENTS table which records their status at the unit a file has most recently been loaded from. We also check for patients with the name REFUSED/CONSENT but that should be in-sync with the flag field. |
UKRDC-TNG Version Control
Nick has asked about using a Development branch in git so that the Master Branch should be in a state to compile/deploy. At the moment he is tagging releases but Bamboo is not able to use those as the source of a build.
I have asked Nick about whether we should have a separate Development Branch ourselves and also what he thinks we should do about changes to Mirth Channels. He replies:
It is a recognized practice to have feature branches off develop so that multiple teams can work independently of each other. However, that is not without cost and those changes have to be reviewed and merged at some point.
I don’t think we have enough parallel development going on to justify that so I think that you would make changes to the same dev branch. We need some communication but so long as you commit regularly to the dev branch and I check before pulling a release back to master, that should be ok.
I don’t think I’d trust git to diff Mirth changes and automatically merge reliably though I’ve not tried it. Not sure we need a separate lock either.
One way which might work at this point is for you to take control of the channels in git. Changes should be small from here on and together with my location, you guys might be best placed to support the channels directly. Happy to problem solve and assist but if you control updates to the channels and I control updates to the Java that might work?
We need to decide how we want to work and then left Nick know.