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 Matlab.
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
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