EPICS: Distributed Development, Distribution, and Support
At the present time no site has the resources to form a group
of people to provide centralized support for the EPICS community.
The most any site can provide is the equivalent of 1-2 person
years per year.
This document describes procedures for developing, distributing
and supporting EPICS in a distributed manner.
Only three centralized functions are defined.
EPICS release coordination
New releases will be scheduled. The contents of each release will be
determined several months before a release.
The EPICS release coordinator is responsible for managing these tasks.
The master EPICS sources will be maintained at a single site,
the integration site.
EPICS development coordination
The EPICS development coordinator is responsible for managing
the overall development effort and generating new releases.
Each supported platform will have an individual responsible for development,
the platform developer.
Each software component will have an individual responsible for development,
the product developer.
A product developer coordinates with the development coordinator
before checking in changes to the master sources.
Platform developers will be notified when the changes have been made.
All product changes made by a platform developer must be coordinated
with the product developer and with the EPICS development coordinator.
The initial point of distribution for each platform is the platform developer.
Each set of related users should join together so that they have a single
person interacting with the platform developer.
Each set of related users should provide for supporting their
The mail groups epics_applications and tech-talk are the primary
means for EPICS wide support.
Overview of Development and Distribution
Although the following are presented as consecutive steps,
it is recognized that iteration is involved. Thus problems at a
later step often make it necessary to back up to previous steps.
In addition as much parallelism as possible should be used.
For example platform developers should not wait until
all of EPICS has been built and tested at the integration site
before building and testing. Instead they should build and test each
portion when the release coordinator says that it is ready.
Release contents and schedule
- Via collaboration meetings, e-mail, etc. all sites give
input to the release coordinator about what should go
into future releases.
- Release coordinator determines future release contents
- Release coordinator monitors release progress.
Release generation and distribution
- After testing at local sites, product and platform developers
update the master EPICS sources.
- The development coordinator builds and tests the master sources.
- The development coordinator notifys the platform developers
that new or updated products are available.
- The platform developers build and test at their platform development
- The platform developers announce that the new version is available
for their platform.
- Whoever is responsible for groups of users obtain the new version from
the platform developers.
EPICS development, distribution, and support is done in a distributed manner.
This means that individuals at many EPICS sites are involved.
In order, however, to prevent EPICS from evolving into many
incompatible versions, some centralized functions must exist.
Release Contents and Schedule
Anyone in the EPICS community can have input into what should be
in releases and when releases should be scheduled. Without
coordination, however, this would be unmanageable. Thus a
release coordinator is assigned to manage this task.
EPICS Integration Site
At least for now a single EPICS integration site is designated.
This site will maintain a CVS repository for the master
EPICS sources. Platform and product developer, under the direction
of the development coordinator, will make changes to this
repository in preparation for new releases.
In the future only a core part of EPICS should be kept
at the centralized location (base and some extensions).
Other products will be maintained at distributed sites.
For example hardware specific support and individual extensions
can be managed in a distributed manner.
EPICS development coordinator
This person is the point of contact for changes to the master
EPICS sources. Developers making changes must coordinate with
this person. In addition if developers are making changes to products
that do not belong to them, they must also coordinate with the person
responsible for the product.
EPICS Integration Site
The development coordinator maintains a CVS repository for the master
EPICS sources. This repository is for the exclusive use of EPICS,
i.e. it is not used to store local sources.
The development coordinator will manage the CVS repository and build
new releases from it.
Each platform has an platform developer responsible for building new
releases on that platform.
There may only be partial support. The extent of support will be described
by the individual responsible for the platform.
In order to prepare new releases the platform developers interact
with the development coordinator. This is an iterative process that
works something like the following:
These steps are repeated until it is decided that things are working
well enough to announce a new release.
The development coordinator announces that a new version
of the master has been built.
Platform developers obtain the latest sources and build it for their platform
As problems are discovered, changes are made to the master sources.
If a platform developer finds it necessary to modify any source code,
he/she must coordinate with the product developer as well as with the
Each product has a person assigned the responsibility of maintaining
NEEDS NEW PROCEDURES DEFINED!!!
The existing Source/Release control manual describes procedures
for using the EPICS CVS repository. It does not, however,
describe procedures that allow a developer to maintain
a CVS repository at a local site that is kept in sync with the
master site. We MUST define such procedures before new developers
start modifying the master CVS repository. We have already had
a couple of cases where remote users accidentally caused changes
made by others to be lost when issuing a cvs commit command.
In addition remote developers have had problems getting their remote
CVS tree back in order whenever a change was made to the directory
Each platform developer will be a distribution source for that platform.
Groups of users are encouraged to provide distribution sources
derived from the platform developer sources.
The reason is that users normally need help building EPICS at their local sites.
The only thing the platform developer is expected to provide is a place
to obtain EPICS. He/she is not expected to provide support, i.e. answer
questions, from all users of that platform.
??? What are the procedures for obtaining EPICS from platform developer.
Is password protected ftp sufficient?
EPICS does not provide any centralized support group.
The only centralized help is that available via the list-server groups
epics_applications and tech-talk.
It is up to each group of users to provide their own support.
All of the following are volunteers.
Assignment of Responsibility
EPICS release coordinator: Bob Dalesio
EPICS integration site: ANL/APS
EPICS development coordinator: Janet Anderson
Each platform has a responsible individual as listed below. For many platforms
there may only be partial support. The extent of support will be described
by the individual responsible for the platform.
The current assignments are as follows:
Sunos - Mike Bordua
Solaris - Andrew Johnson
HPUX - Johnny Tang
Silicon Graphics: Mark Rivers, Ed Desmond
DEC OSF1 - Tony Cox
DEC VMS - Mark Rivers
Windows NT - Chris Timossi
Linux - John Quintana
Configuration and makefiles
All files except platform specific files are the responsibility of the
development coordinator(Janet Anderson).
Mike Bordua and Matt Needes are responsible for defining CVS procedures
for modifying and accessing the master EPICS sources at the integration
as - Marty Kraimer
ascii - Whoever owns associated support
bld - Marty Kraimer
ca - Jeff Hill
db - Marty Kraimer (dbEvent belongs to Jeff Hill)
dbtools - Jim Kowalkowski
dct - Frank Lenkszus, Marty Kraimer, Bob dalesio
dev - See Hardware support below.
devOpt - See hardware support below.
dev - See hardware support below.
assert - Jeff Hill
bdt - Not Assigned
bucketLib - Jeff Hill
calcPerform - Janet Anderson
cvtBpt - Janet Anderson
cvtFast - Marty Kraimer
ellLib - ........
envSubr* - Andrew Johnson
err* - Jeff Hill
fdmgr - Jeff Hill
freeListLib - Marty Kraimer
gpHashLib - Marty Kraimer
memDebugLib - Jeff Hill
nextFieldSubr - Is this still needed?
pal* - Matt Stettler
post* - Janet Anderson
realpath - ?
sun4ansi - Janet Anderson
tsSubr - ?
libCompat - ?
libvxWorks - Jeff Hill
rec - See hardware support below
rsrv - Jeff Hill
sequencer - Andy Kozubal
toolsComm - M. Kraimer
util - Jeff Hill
- recAai - Johnny Tang
- recAao - Johnny Tang
- recAi - Janet Anderson
- recAo - Janet Anderson
- recBi - Janet Anderson
- recBo - Janet Anderson
- recCalc - Janet Anderson
- recCompress - Janet Anderson
- recDfanout - Johnny Tang
- recEg - M. Kraimer
- recEgevent - M. Kraimer
- recEr - M. Kraimer
- recErevent - M. Kraimer
- recEvent - Janet Anderson
- recFanout - Janet Anderson
- recGsub - Roselle Wright
- recHistogram - Janet Anderson
- recLongin - Janet Anderson
- recLongout - Janet Anderson
- recMbbi - Janet Anderson
- recMbbiDirect - Johnny Tang
- recMbbo - Janet Anderson
- recMbboDirect - Johnny Tang
- recPal - Matt Stettler
- recPermissive - Janet Anderson
- recPid - Janet Anderson
- recPulseCounter - Marty Kraimer
- recPulseDelay - Marty Kraimer
- recPulseTrain - Marty Kraimer
- recScan - Ned Arnold
- recSel - Janet Anderson
- recSeq - M. Kraimer
- recState - Janet Anderson
- recSteppermotor - Bob Dalesio
- recStringin - Janet Anderson
- recStringout - Janet Anderson
- recSub - Janet Anderson
- recSubArray - Carl Lionberger
- recTimer - Bob Dalesio
- recWait - Ned Arnold
- recWaitCa - Marty Kraimer
- recWaveform - Janet Anderson
Driver and Device Support
THIS NEEDS VOLUNTEERS??
The following only provides for a subset of what is being provided in the 3.12.
In addition we need documentation for many of the devices.
- Allen Bradley: Marty Kraimer, Bob Dalesio
- VXI Resource Manager: Jeff Hill
- GPIB Drivers and Library: M. Kraimer
- BITBUS Driver: M. Kraimer
- HIDEOS: Jim Kowalkowski
- XYCOM - Matt Needes
- alh: Janet Anderson
- appSR: Janet Anderson
- ar: Deb Kerstiens
- burt: M. Kraimer
- ca: Ben-Chin Cha
- camonitor: Janet Anderson
- cau: Deb Kerstiens
- condition: Mike Borland, Claude Saunders
- dalib: Claude Saunders
- dp: Janet Anderson
- edif: Matt Stettler and Matt Needes
- ezca: Marty Kraimer
- gvxi: Jim Kowalkowski
- hideos: Jim Kowalkowski
- km: Ken Evans
- knobconfig: Claude Saunders
- libUnix: Janet Anderson
- math: Ben-Chin Cha
- mdct: Jim Kowalkowski
- medm: Ken Evans
- medm_cebaf: ?
- motifButton: Janet Anderson
- namecapture: Ken Evans
- opi: Deb Kerstiens
- orbitscreen: Ken Evans
- popup: Ken Evans
- probe: Ken Evans
- pvwave: Ben-Chin Cha, Mark Rivers
- rampload: Mike Borland, Claude Saunders
- scopeutil: Claude Saunders
- sdds: Mike Borland, Claude Saunders
- sddsapps: Mike Borland, Claude Saunders
- snaps: Ben-chin Cha
- stripTool: Janet Anderson
- tcl: Ben-chin Cha
- tcl_et: Bob Daly
- tcl_it: Bob Daly
- tcl_select: Ben-Chin Cha, Claude Saunders
- wingz: Ben-chin Cha
- xmca: Ben-chin Cha
- xmseq: Ben-chin Cha
Distribution and Support
This section describes known distribution and support sites
and who they are willing to support. Again remember that
the only global support is via the epics_applications and
tech-talk mail groups.
Supports the accelerator systems division. In addition
it is the distribution source for ANL/APS/XFD.
Supports the APS Users.
Supports CEBAF and CEBAF experimenters
Supports everyone not supported by others
Supports LBL users
(?Organization) Andrew Johnson
- Janet Anderson - email@example.com (APS/ASD)
- Ned Arnold - firstname.lastname@example.org (APS/ASD)
- Mike Bordua - MGBordua@lbl.gov (LBL)
- Ben-Chin Cha - email@example.com (APS/XFD)
- Tony Cox - firstname.lastname@example.org (Synchrotron Radiation Community)
- Bob Dalesio - email@example.com (LANL)
- Bob Daly - firstname.lastname@example.org (APS Users)
- Ken Evans -email@example.com (APS/ASD)
- Jeff Hill - firstname.lastname@example.org (LANL)
- Andrew Johnson - email@example.com (Telescope Community)
- Deb Kerstiens - firstname.lastname@example.org (LANL)
- Jim Kowalkowski - email@example.com (APS/ASD)
- Andy Kozubal - firstname.lastname@example.org (LANL)
- Marty Kraimer - email@example.com (APS/ASD)
- Frank Lenkszus - firstname.lastname@example.org (APS/ASD)
- Steve Lewis - SALewis@lbl.gov (LBL)
- Bill McDowell - email@example.com (APS/ASD)
- Tim Mooney - firstname.lastname@example.org (APS/XFD)
- Matt Needes - email@example.com (LANL)
- Claude Saunders - firstname.lastname@example.org (APS/ASD)
- Mark Rivers - RIVERS@cars3.uchicago.edu (Synchrotron Radiation Community)
- Matt Stettler - email@example.com (LANL)
- Johnny Tang - firstname.lastname@example.org (CEBAF)
- Chris Timossi - CATimossi@lbl.gov (LBL)
- Dave Wallis - email@example.com (APS/XFD)
- Chip Watson - firstname.lastname@example.org (CEBAF)
- Rozelle Wright - email@example.com (LANL)
- ???Who else should we list in this document???