Location

Cambio office, Drottninggatan 89, Stockholm

Physical Attendees

Rong Chen
Erik Sundvall
Thomas Beale
Bjørn Næss (DIPS ASA)
Sebastian Iancu
Bostjan Lah

Planned Outcomes

agreed plan to release RM 1.0.4
agreed plan to release ITS for RM 1.0.4
agreed plan to release AM 2.0
SM - APIs progress

Agenda Suggestions

Specifications Releases
- RM Release 1.0.4 to fix minor 1.0.3 bugs? - Thomas Beale
- AM 2.0 release - Thomas Beale
- ITS release strategy - Sebastian Iancu
  - does ITS continually accumulate mutually consistent sets of resources, e.g. XSDs, Java code etc etc? It should be the case that the ITS project has ITS for every other component that has something available at any time.
- ITS - specific discussion on XSDs
- RM Release 1.1 - move most of Common to BASE
- SM first release timetable
- status of UML tooling, extractor, documentation approach, global UML site to replace broken MD one?
GDL & ADL rules
- GDL UML models need to be converted to MagicDraw - then can use class extraction documentation approach.
- need to rationalise AOM2 rules and GDL rules.
SM & REST APIs - Former user (Deleted)
- Algorithm for converting archetype paths => URIs for REST - Thomas Beale
ADL2 - IM/RC/TB
- adoption pathway for industry
- open tooling project; multi-vendor collaboration; possible funding; Maybe also Google Summer of Code https://developers.google.com/open-source/gsoc/ (org application deadline Feb 19)
- How should the openEHR community organize the development of the needed tools for clinical modelling?
TDS2 - wiki dev page
- we need a formal specification - where does it live?
- TDD => canonical converter specification
How to formalize AQL
- Proposed syntax for AQL syntax for status of INSTRUCTION/ACTIVITY
- Proposed syntax to allow AQL querying across links/ references (possibly relates to item above)

Agenda

Programme				Virtual attendees
Thursday 11 Feb		Who	Actions	PP	HF	KA	DB	IM	SK
09:30 - 10:00	Informal - get set up with Jira, screens, GTM	All
10:00 - 10:30	Tooling Git strategy / workflow Review workflow - BN	All
10:30 - 11:00	Documentation tooling update - show everyone how tooling is working at the moment; solicit suggestions for improvement. MagicDraw?!	Thomas Beale
11:00 - 11:30	Global review Review long term release plan triage out: actionable / need discussion / defer
11:45 - 12:15	ITS release strategy	All
12:15 - 13:15	LUNCH
13:15 - 14:15	ITS release strategy - Sebastian Iancu does ITS continually accumulate mutually consistent sets of resources, e.g. XSDs, Java code etc etc? It should be the case that the ITS project has ITS for every other component that has something available at any time. ITS specifics - RM 1.0.3 XSDs	Sebastian
14:15 - 15:15	Specifications Releases RM Release 1.0.4 to fix minor 1.0.3 bugs? - Thomas Beale AM 2.0 release - Thomas Beale
15:15 - 15:30	C O F F E E
15:30 - 16:30	Specifications Releases RM Release 1.1 - move most of Common to BASE SM first release timetable
16:30 - 17:30	ADL2 migration strategy	TB
17;30 - 18:00	Cambio - GDL state of the art	Rong
20:30 -	Dinner

Friday 12 Feb
09:00 - 10:15	TDS2
10:15 - 10:30	C O F F E E
10:30 - 11:00	REST APIs
11:00 - 12:15	REST APIs
12:15 - 13:15	LUNCH
13:15 - 13:30	AQL
13:30 - 14:30	AQL
14:30 - 14:45
14:45 - 16:00
	drinks? :)

Actions

Vagrant

Create list of instructions for vagrant provisioning script for documentation / publishing env. Sebastian to build and test.

MagicDraw

Do a test to see if MD XMI includes all model content including diagrams.

Do a test to transfer full model to another tool.

GDL

ROng - send TB XMI of GDL model.

Publishing / Workflow

Asciidoc or other generic small types - use a 'collector' CR on each release e.g. 'Correct Asciidoc syntax errors' - e.g. SPECPUB JIRA project.

Signficant CR-driven changes:

agree on private fork + change + pull request + merge

Changes is done one personal fork
Pull request is sent to main repository
Owner of that specification Git repo will do the merge
Each commit must be assigned with a prefix for the JIRA item (e.g. SPECRM-35)

UML changes - discuss/agree in JIRA, then component owner does or delegates UML changes to one person - avoid competing UML model changes.

Review workflow options - e.g. external reviewers:

Component owner does
- AsciidoctorFX export to ODT
- generate HTML in the normal Asciidoctor way
reviewer uses e.g. OpenOffice to markup - comments & changes, then returns to owner who then processes manually.

Git branch philosophy

option #1 - single master
option #2 - master = dev branch; create interim branches on demand if need to apply selected later commits at an earlier point.

ITS strategy

Per-component ITS-RM, ITS-AM, etc Git repos with file structures like:

ITS-RM repo:

tag point: 1.0.2
- CHANGELOG.txt
- xml
  - xsd
tag point: 1.0.3
- CHANGELOG.txt
- xml
  - xsd
    - 6 files
  - xslt
tag point: 1.0.4
- CHANGELOG.txt
- doc
  - sdfsdfdf
- xml
  - xsd
    - 6 files
  - schematron
    - 2 files
  - xslt
    - xxx
  - examples
    - xxxx
- json
  - xxx

Each repo would use same tags as SPECIFICATION-xx repos, e.g. 'Release-1.0.3'.

To add updates to an earlier release, e.g. fix 1.0.2 XSD bug, or add JSON schema to 1.0.2, then do a branch off the relevant tag point and use tags like 'Release-1.0.3-R2' etc.

Can also add secondary 'bundle-based' tags e.g. '2016.3', '2017.6' etc.

Manually maintained CHANGELOG.txt file in root - enables consumers to easily find out what has changed.

Long term release?

Additionally, a 'whole of system' ITS repo containing e.g. whole of system documentation, packaging scripts etc.

Conformance

Release naming: use e.g. Release-2016.3?

Question: how to connect conformance resources/test plans etc to ITS artifacts.

SEC Feb 2016 Meeting