Minutes of TELECON 9/Jul/2013

SEE MINUTES BELOW AGENDA

Agenda as followed

Trying to resolve some of the questions of what it means to be in a "release", is it

different to what's in a tarball, and intention of examples.

1. Release numbering

What is the intention of version number tracking?

Let me try to reduce this to a question:

Should we have a) on one release number for all modules of "core" (and no other numbers), or b) one release number

for all of core, which implies release numbers of all dependencies (internal and external).

a) [per http://epics-pvdata.sourceforge.net/release.html#module_versions_covered]

pvData    4.3.0.0

pvAccess  4.3.0.0

pvIOC     4.3.0.0

alpha     4.3.0.0

example   4.3.0.0

pvaSrv    0.9.1      <- somehow other than "core"

b)

"epicsv4CPP" 4.3.0.0

-> pvData 2.1.0-someext

-> pvAccess 1.3.1

-> pvIOC 1.32.3

-> pvaSrv 0.9.1

-> exampleCPP 1.3.0


2. Should pvaSrv in "core"?
What is the meaning of "core".

3. What should be in tarballs we produce as part of release? "core" only, or other things too?

4. What is the intention of the examples modules. Will they be included in the "release"; will

they be in the tar?

[1] http://epics-pvdata.sourceforge.net/home.html#usefulinfo

Minutes

PRESENT:  AJ,DH,GW,MS,MK,SV

SCRIBE:  MK

CHAIR: GW

NEW TOPIC 1. Release numbering

What is the intention of version number tracking?

Let me try to reduce this to a question:

Should we have a) on one release number for all modules of "core" (and no other numbers), or

b) one release number

for all of core, which implies release numbers of all dependencies (internal and external).

http://epics-pvdata.sourceforge.net/release.html

GW: When are dates for  release

AJ: In document above.

Back to release numbering.

GW: Move to synapps-like numbering system

AJ:OK and will update release.html

Resolution: Each package will have its own version number which follows major, minor, etc conventions but without the leading 4. There is also an overall separate version number for the core with a leading 4 which covers the collection of packages that are released together. Both numbers appear as tags in Hg.

SV: also follow synapps which shows exact release number of each component.

Discussion about maven.

MS: Should be OK with maven.

SV: For Java jar file must have release number.

GW: For eclipse zip file for source.

MS: everything should go in jar files. One jar for source, one for binary, one for javaDoc.

MS & SV: Each jar has version on it’s name. Overall tar contains individual jars.

GW: What does user download

SV: Single tar file that has jar file, which has individual jars.

Example

epics-java-4.3.tar.gz expands to

epics-java-4.3/

    lib/

       pvData-2.2.jar

       pvAccess-5.3.1.jar

etc.

epics-cpp-4.3.tar.gz expands to

epics-cpp-4.3/

    pvCommonCPP-3.0/

    pvDataCPP-3.1/

etc.

********

NEW TOPICS:

2. Should pvaSrv in "core"?
What is the meaning of "core".
3. What should be in tarballs we produce as part of release? "core" only, or other things too?
**********

AJ: Should examples be included?

SV GW: Yes

Resolution: Associated modules like exampleCPP and exampleJava, and pvaSrv will be included with the core modules in the tar release files.

On alphaJava, which presently contains easyPVA.

Discussion about if easyPVA should be part of release.

SV, MK, MS thinks history of module contents can be “moved” from one repo to another by “hg move”.

MS:  Can make easyPVA  separate module.

Discussion about if should be moved.

Resolution: easyPVA Will be moved out of alphaJava with a 0 major release number.

Also test to see if hg move moves history.

alphaJava will remain as a skeleton directory, but not be included in core release.

AI: on MS to move easyPVA out of alphaJava.

AI: on AJ: Add easyPVA to the components of the release for java.

**********

NEW TOPIC

4. What is the intention of the examples modules. Will they be included in the "release"; will

they be in the tar?

**********

GW: last topic is channel archiver and RDB.

Are these just examples?

GW thinks yes and should remain so.

But start a new effort to develop services for science for archiver and RDB.

PSI and SLAC interested. Is DH also interested?

At Diamond meeting Bob discussed.

GS: almost two year colloboration between BNL and MSU.

GW: three groups: BNL/MSU, core group, new one for RDB and archiver

GS:  BNL/MSU collab already does this.

GW: not sure. What are they pursuing?

GS: RDB WG has meeting every Wednesday including BNL, MSU, ESS, COSYLAB, and IHEP.

Conclusion:

Channel archiver example and RDB service example will remain in example repos, intended to illustrate methods, not efficiency or features. Separately, production quality services are

expected to be developed elsewhere, by different teams.

Feature freeze now except easyPVA.

Next step:

Each package has someone responsible. That person must tag package and send email to working group. Andrew will keep track of progress.

AJ: Updated table 5.2 from release.html file

Package & Version

Module

Module Version

Module Owner

epicsJava 4.3.0

pvDataJava

3.0

Marty Kraimer

pvAccessJava

3.0

Matej Sekoranja

exampleJava

3.0

Greg White

easyPVAJava

0.1

Matej Sekoranja

epicsCPP 4.3.0

pvCommonCPP

3.0

Matej Sekoranja

pvDataCPP

3.0

Marty Kraimer

pvAccessCPP

3.0

Matej Sekoranja

pvIOCCPP

3.0

Marty Kraimer

exampleCPP

3.0

David Hickin

pvaSrv

0.9.1

Ralph Lange

Meeting ends, 10:00 am