EPICS: Distributed Development, Distribution, and Support
Introduction
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.
Centralized Functions:
-
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.
-
EPICS integration.
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.
Development Procedures:
-
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.
Distribution Procedures:
-
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.
Support Procedures:
-
Each set of related users should provide for supporting their
own users.
-
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
and schedule.
- 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
site.
- 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.
Centralized Functions
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.
Development Procedures
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.
Platform Responsibility
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:
-
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.
These steps are repeated until it is decided that things are working
well enough to announce a new release.
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
development coordinator.
Product Responsibility
Each product has a person assigned the responsibility of maintaining
that product.
CVS procedures
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
structure.
Distribution Procedures
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?
Support
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.
Assignment of Responsibility
All of the following are volunteers.
Centralized Functions:
-
EPICS release coordinator: Bob Dalesio
-
EPICS integration site: ANL/APS
-
EPICS development coordinator: Janet Anderson
Platform Responsibility
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
Product Responsibility
Configuration and makefiles
All files except platform specific files are the responsibility of the
development coordinator(Janet Anderson).
CVS Procedures
Mike Bordua and Matt Needes are responsible for defining CVS procedures
for modifying and accessing the master EPICS sources at the integration
site.
Base/src
-
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.
-
libCom
-
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
Record/Device/Driver Responsibility
-
Record Support
- 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
Extension Responsibility
- 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.
-
ANL/APS/ASD
Supports the accelerator systems division. In addition
it is the distribution source for ANL/APS/XFD.
-
ANL/APS/XFD
Supports the APS Users.
-
CEBAF
Supports CEBAF and CEBAF experimenters
-
LANL
Supports everyone not supported by others
-
LBL
Supports LBL users
-
(?Organization) Andrew Johnson
Supports Gemini
-
Others??????
E-Mail Addresses