All the members of the project are involved in the Software Configuration Management activities. Basically:
Actually in this project the same actor can be in charge of many activities.
On a technical point of view, the environment consists in:
The Software Configuration Management process applied to this project identifies many types of baselines ; each of them has specific identification rule and minimum verification characteristics. For more details about verification, see Software Verification Plan.
All the development artifacts (source code, makefile, documentation) are identified and managed under configuration.
Working baseline:
Unstable baseline:
Stable baseline:
Official baseline:
The baselines are identified through CVS services, mainly with tag management.
The traceability between baselines may be analyzed through the CVS browser available on Savannah.
An unstable baseline shall be established at developer initiative when the developer wants to backup its working area in the public area.
A stable baseline shall be established at developer initiative when the developer wants to identify a particular state of the development.
An official baseline shall be established at project manager initiative, when a consistent batch of modifications have been fully implemented, verified and tested.
Problem reports and enhancement requests are named as change requests in the next paragraphs.
Change control is not used for development or unstable releases. Consequently any change request refers to a baseline fully identified in the configuration management system.
Change request reporting is available through the Savannah bug tracking system.
Anybody can raise a change request. This change request shall include the identification of the concerned component. It may also include a priority.
The project manager receives a notification for each new change request. The project manager shall define the priority and affect a responsible for the implementation of the request. Eventually the project manager can cancel a change request.
Problem reports can be fixed on the release on which the defect has been found (by patch) or on a later release according to the criticity of the problem (for instance if the consequence of the defect can be a loss of data, it shall be fixed on the release on which the defect has been found). If the release on which the defect has been found is very old, this release may be declared “forbidden” and removed from the download area. In this case the defect will be fixed on a later release.
Each developer can close a change request. Before closing a change request, the developer shall identify the baseline in which he implemented the needed modifications (generally as a stable baseline). During the closure of the change request, the developer shall define the baseline in which the change request is implemented.
Configuration status accounting is available through CVS services.
During the definition of unstable baselines, the developer shall write a summary of the implemented modifications. This information is then available through CVS services and the Savannah CVS Browser.
During the definition of official baselines,
the project manager shall fill in the ChangeLog of the project. This ChangeLog
is a synthesis of modifications implemented since the previous official baseline.
The project manager shall also ensure that all the documentation is up-to-date
and he shall build a tarball of the whole documentation tree ; this tarball
shall be downloadable in the Savannah Files section, associated with the
distribution tarball of the application.
Archive, retrieval and release are available through CVS services.
The project manager shall archive distribution tarballs of official baselines on the download area of Savannah.
Consequently distribution tarballs of official baselines may be downloaded on the download area of Savannah.