Environment
All the members of the project are involved in the Software Configuration Management activities. Basically:
- the developers implement software enhancements and report, analyze and fix defects.
- the software configuration manager is responsible for baselines identification
- the users may use the software configuration management system to retrieve a particular baseline, to report defects or to propose software enhancements
- the testers report defects
Actually in this project the same actor can be in charge of many activities.
On a technical point of view, the environment consists in:
- savannah bug tracking system
- CVS hosted on savannah
Configuration identification
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:
- Description: this is a development baseline in the private working area of a developer. This baseline is not identified since it is a private one.
- Identification: none
- Minimum characteristics: none
Unstable baseline:
- Description: this is a development baseline in the public area of CVS.
- Identification: this baseline is not identified. It is only accessible as the 'latest' one.
- Minimum characteristics: none
Stable baseline:
- Description: this is a development baseline in the public area of CVS. This baseline identifies a consistent set of modifications or an important step during the implementation of a modification.
- Identification: a stable baseline is identified according to the involved GHOSTS component and the current date : [GHOSTS|GEDCOMPARSER|GEDCOMVIEWER]_YYYYMMDD
- Minimum characteristics: a stable baseline shall be at least compilable / linkable.
Official baseline:
- Description: this is a user baseline in the public area of CVS. This baseline identifies a consistent set of modifications; those modifications are well implemented, verified and tested.
- Identification: an official baseline is identified according to the part of the involved GHOSTS component and the release identification:[GHOSTS|GEDCOMPARSER|GEDCOMVIEWER]_Vx_y_z (Vx_y_z may use several digits forx y and z). The z member is used to trace corrections on an official baseline. The y member is used to trace enhancements which do not modify the scope of the current version. The x member is used to trace evolutions that modify the scope of the version.
- Minimum characteristics: an official baseline shall be fully implemented, verified and tested.
Baselines and traceability
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 reporting - Change control - Change review
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
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
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.
