EPICS V4 TELECON, 25-MAR-2014
New meeting time. Proposal for 1/2 hr earlier.
1. Why so many "failing" builds? (10 mins)
2. Review Marty's "proposed changes" and associated AIs    (30 mins)
3. Lock-up in pvAccess (10 mins).
What was this issue, why will a codec version fix it?
4. NTNDArray proposal review, and Andrew's comments  (10 mins)
5. Early thinking on next release (if time, may be next week)
What will be in it?
- wait for pvGrp from Ralph?
- pvDatabase included or not?
- Bundle pvaPy?
- Bundle matlab wrappers?
 Diff of previous proposedChanges_3_0 to this new one - they are extensive,
PRESENT: AJ, SV, MK, GW, DH, MS
Check with Bob on new meeting time,
- May have to revisit meeting time for Bob and Matej
NEW TOPIC: Why so many failing builds
AJ: pvDatabase has bug in example in
You need to adjust the release file in the exampleServer subTop
AJ: Windows problems are in name decorations.
MS: No decorations for pvDatabase at all
AJ: Not sure why pvaSrv-win64 jobs are failing. There is a test failing in pvAccess [MS understands].
AJ: Can MS take a look at the errors in the build serve [for pvaSrv Win64 and 64s]. May be c++ issue.
NEW TOPIC: Review Marty's "proposed changes" and associated AIs
GW: Should a cookbook be in general module?
MS: Cookbook is only about pvData.
GW: It needs to be published automatically by Jenkins build.
AJ: There is a script in cloudbees subdirectory that does sync. It should be possible to use this script.
MS: It’s a very short text file.
AI on MS: Matej makes cookbook automatically published by Jenkins.
AI on MD: Review the documentation about shared_vector in present pvDataCPP.html and new implementation of PVArrays
ISSUE: MS and MK do not have Windows, vxWorks or RTEMS themselves for development, so when there is a build issue they can’t easily fix it.
AJ will closely observe and help with problems in Windows, vxWork and RTEMS.
In general we agree that responsibility for a module’s health rests with the module owner but if another programmer breaks it they have responsibility to fix it.
AJ: Currently default branch is inactive.
MK: I need to solve this.
AI on MS: Fix pvDataCPP repository to have a default branch back (not “inactive”).
GW: We need to define standard for a syntax for using const.
MS: No need, use C++ books.
AI on DH: Implement changes w.r.t. const (proposed changes 7.1)
MK: I not remove “deprecated” method in Java, since pvIOCJava depends on them (XML parsers). And I use pvIOCJava for testing.
GW: Can we deprecate pvIOCJava (remove pvIOCJava from next build) for some time.
AI on MK: pvField Methods (7.2) will be removed from CPP modules, however they will only be marked deprecated in Java.
AI on MS: Make the changes to pvAccess API in both Java and C++.
AI on MK: Make changes in pvDatabaseCPP, pvIOCJava.
AI on RL: make pvAccessAPI changes w.r.t. proposed changes (Sec 10) in pvaSrv.
Ai on MK: Review and make changes to pvDatabaseCPP to pvCopy and local channel provider per Proposed Changes sec 13.
NEW TOPIC: NTNDArray proposal review, and Andrew's comments
DH: Did not renamed “reverse” to “reversed” since the equiv is named reverse in areaDetector.
Did make it boolean. Binning is still an int.
AJ: So binning tells you how it’s binned, not whether binned or not?
DH: correct. Conventionally 1 means there is no binning.
MS: Should I add NTNDArray to eget and CSS (Vtypes)?
GW: Don’t want MS to work on CSS too much.
MK: Should GW email BD to ask GC to work on this?
MS: I can create mapping for Vtype, done this before.
MS does need a vtype from Gabrielle to which to map, so requires input and action from Gabriele.
AI: on GW write BD on priority of NTNDArray support in CSS (v-types).