Workplan HowTo

The JRA1 workplan is maintained in a Savannah task tracker. The purpose is to provide a unique place where all the information on the most significant activity performed by JRA1 developers is collected.

A task is typically justified by a requirement coming from the users (operations or applications), possibly mediated by the TMB. A task can also be opened independently by a product team, for example when the corresponding development concerns an improvement anticipating issues in scalability, reliability, performance, etc.

Release Schedule

The Release Schedule is a subset of the workplan tasks showing the roadmap of gLite components under the responsibility of JRA1, in terms of their releases. All releases, scheduled and unscheduled (emergency), major, minor and revisions, should appear in the Release Schedule. This allows to have a complete history of the releases.

When opening a release task:

• The summary should have the form [name of the component] release x.y.z-w.

• The Should be finished on date is an estimate of when the corresponding release will enter certification. A month resolution is sufficient. If necessary, the date can be changed.

• A corresponding Savannah patch should be opened at the same time and linked to the task with a dependency task -> patch. The summary of the patch should have the same value of the task summary, possibly extended with platform information. Multiple patches, e.g. one per platform, can be attached to a release task. The existence of the patch very early in the process allows to attach a bug to a patch as soon as the bug is accepted.

• The comment in Original Submission should provide a short description of the main changes in the release. If a change is associated to an existing task, a dependency on that task can be set.

A patch entering certification should always be associated to a release task. For scheduled releases, the task should be opened well in advance. For unscheduled (emergency) releases, the task can be opened at the last minute.

When a patch enters certification, the Status of the corresponding task is set to Done, but the Open/Close field is left Open. The task is closed when the release enters production. If the patch is rejected or sent back to the developers (in Status With Provider) the release task is set back to Assigned.

Versioning

Every release should be versioned according to the usual major.minor.revision-age schema:

• a major release of a component is characterized by a well-defined interface and behaviour;

• within a major release, a minor release of a component can introduce changes in interface or behaviour in a strictly backwards-compatible way;

• within a minor release, a revision release of a component introduces only bug fixes;

• a change in age means a simple re-build of the component, without any changes, neither in code nor in configuration.

-- FrancescoGiacomini - 13-Oct-2009