User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
Build Identifier: 

User story:

As a user I want to clone an existing content view so that I can clearly distinguish between engineering releases, release candidates and general availability releases. I need a clone operation to guarantee that e.g. my GA release is identical to my final release candidate.

Scenario:

Acme Co linux engineering group are tasked with engineering and releasing RHEL builds to a variety of internal customers, for whom all builds should be considered production builds.

The Environments are setup as follows:

Library->Crash->Production

(this is simplified - in fact there are several 'production' environments but from the POV of the linux engineering group, they are all production and only GA releases should be sent there.

During the development cycle of the ACME-6.5.0 RHEL build, the following content views are used:

6.5.0-ci - this build exists only in Library and is constantly refreshed in a continuous integration environment. The refresh is scripted form Jenkins.

6.5.0-sp1..n - these content views are produced at the end of each sprint. The content view is created in Library then promoted to Crash where more extensive tests are carried out than are carried out on the ci builds.

6.5.0-rc1..n - these are release candidates. 6.5.0-rc1 is created by CLONING the final sprint build (6.5.0-sp<n>). Subsequent release candidates are created by revising 6.5.0-rc1 (filters etc). This content view is promoted to Crash for extensive testing, demo-ing etc.

6.5.0-ga - this is our general availability release. It is created by CLONING the final release candidate (6.5.0-rc<n>) and promoting to the production environment.

Summary:

From the above scenario it should be clear that a clone operation is required to guarantee that the first RC release is identical to the last sprint build, and the GA release is identical to the last RC build.

Reproducible: Always