EPICS V4 Weekly Telecon, 17-Jun-2014



First let's have a pretty free form discussion with contributions from everyone
on what you think is important generally, plus specifically what you think of:
 1. What should be our project priorities
 2. How you think communications should be done outside our group. What is required
    and who can or should do it
 3. How internal project tracking should be done. What tracking are you prepared to

I'd also like to mention this: V4.4 is pretty great. I've been using the service support
features and, subject to some annoyances, it's brilliant. It's fast, stable, and wonderfully
easy to use from inside

1. Recent wind-storm

2. Changes to project and priority tracking

3. Status of merge of the "proposed changes" work.




Present: DH, RL, GW, GS, MD, MK, MS, NM, TK, AJ

Scribe: TK

Chair: AJ


NEW TOPIC: Recent Wind storm


GW: [from agenda email]

Like Marty, I also haven't finished processing my thoughts from the recent "wind-storm". But
some matters emerge.

 - We need some agreement about which user groups we're addressing, and on what
 - Timo's "inventory of things still to be done," and how to get them "understood
   and explained." I feel these are different for different user groups  
 - Priority of the gateway and co-priorties of dbGroup and PvDatabase multi, need
   to be resolved as a matter of priority
 - How we do internal project management needs to be reviewed, re-agreed, so we can
   reasonably assume people will keep up with responsibilities. We have
   a tension between "bureaucracy", effective external communications (outside people
   need to see what we're working on and progress), and effective internal status
   tracking. I'd like us to re-agree on expectations for SF tracker maintenance,
   the dashboard, and the module port status tracking. Also James' doc on "Architectures",
   which should have informed outside people about solutions, never really
   did that, and has been abandoned. Do we update it, or replace it with some other
   way to communicate what Timo referred to above.  

RL: how far did the requirements review go last week.

GW: that was just a first exposure and the review is not completed.

The discussion should continue in Brookhaven.

RL: there is not a single one application that can cover all these requirements. Probably two different applications are needed. Two different names, etc.

More elaboration is needed before a design can be done.

GW: please go ahead and make a design proposal for discussion.

DH: do not worry too much about the users at the moment. Let us go ahead and fix the issues at the moment.

GW: we made a group decision to do these changes and let us go ahead. Is there a broader list of frustrations.

RL: do we need a roadmap document

GW: sorry, I haven’t done it (charter) for this year. Is there real need or interest for such a document.

Charters are intended to show people the activities in the working group, and possibly for organisations that invest resources to the project.

MD: We do not have agreements about issues and writing a document does not help that.

Buy-in is missing.

GW: how do you get buy-in if you dont write it down.

MD: But we did not get buy-in even after writing

MD: why does not everybody write down their individual goals for the group

GW: we should concentrate on the group’s goals

MD: the document contents should come from the individuals

GW: that’s whet we tried to do. Is it desirable to write down the goals.

AJ: we should take a look at the individual goals and try to match them and merge them to make the group goals

GW: we should not try to do things in this group what we do not need in our labs

GW: at large, I have got the functionality that I need and I am using it.

GW: there are different things that controls, scientific and perhaps experimental people want.

MD: control applications do not benefit from RPC-type facilities

GW: objectives between different user groups are different

AJ: the discussion does not seem to be resulting in any conclusions

MD: I would like to write my goals for the coming years, and would like the others to do the same

AJ: should we write down the goals for 4.4.?

GW: it looks that most things for 4.4. are done. There are things still coming after 4.4. (pvGroup, etc.) and those should be written down, too.

AJ: should we collect a list of functionalities that need to be done before 4.4. release?

GW: We wrote a list of things that outside people also can see


GW: update the dashboard (showing the status of different components of the software.)



TK: We shouldn’t be telling EPICS Collaboration meetings to use stuff that isn’t ready for production.

GW: Up to 4.3 we said we were only Beta quality.

TK: Qualifying: don’t raise community expectations improperly. Make it clear what is & isn’t meant for production, but at some point we need to tell people when it’s going to be production ready. Thinking about ESS use.

MS: People expecting V4 will replace V3

TK: Haven’t met too many.

GW: I have, here at SLAC, “is your new IOC ready?” If you’re not actively involved in this group you don’t necessarily know that we’re not aiming at that. Some people want everything to be ready, others only want parts.

TK: Can we specify the scope, what we’re aiming at?

GW: Spreadsheet for each individual project, with function and status in one sheet. Didn’t get it but I was hoping for it.

MD: Agrees with GW, doesn’t see the need for a gateway yet.

DH: Mark (Heron) wants transport on the wire to be PVA, pvaSrv.

GW: Agree, In 4.5 primary objective needs to be dbGroup and GW.

TK: I don’t need a gateway (gw) right now, but I need it to be on the plan.

GW: 4.4 should be production ready with multicast & scientific APIs implemented. 4.5. is for  presenting IOC data in more user-friendly way (dbGroup), hopefully with a Gateway.

MD: I want something I can put in an IOC that CA can’t do.

GW: We made a decision 2 yrs ago not to do that.

TK: Agree, but we’re changing that now.

MS asks MD what are the things that CA can’t do?

MD the motivation for a new protocol are what CA’s not good at:

  1. Can’t access multiple fields from a single record atomically

  2. Flow control is limited, partly by implementation


MK: Also, CA isn’t great for areaDetector, because the data set of an image, is a large set of things, which CA can’t present in one set, but PVA can.


NEW TOPIC: Status of merging the new features for 4.4.


GW: can we get a short list from Matej & Marty and continue next week

GW: can we clean up the dashboard?

MS: Well yes, but can we wait until the release?

GW: sure not now, but before the release.

MK: testing can now start


Meeting closes.