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.

Centralized Functions:

Development Procedures:

Distribution Procedures:

Support Procedures:

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

  1. Via collaboration meetings, e-mail, etc. all sites give input to the release coordinator about what should go into future releases.
  2. Release coordinator determines future release contents and schedule.
  3. Release coordinator monitors release progress.

Release generation and distribution

  1. After testing at local sites, product and platform developers update the master EPICS sources.
  2. The development coordinator builds and tests the master sources.
  3. The development coordinator notifys the platform developers that new or updated products are available.
  4. The platform developers build and test at their platform development site.
  5. The platform developers announce that the new version is available for their platform.
  6. 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:
  1. The development coordinator announces that a new version of the master has been built.
  2. Platform developers obtain the latest sources and build it for their platform
  3. 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

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?


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:

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:

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.


Record/Device/Driver Responsibility

Extension Responsibility

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.

E-Mail Addresses