Release process proposal

[Itamar Heim]

On 02/19/2012 03:51 PM, Ofer Schreiber wrote:
>
> ----- Original Message -----
>> Since we currently doesn't have any official Release process, here's
>> my proposal:
>>
>> 1. oVirt will issue a new release every 6 months.
>>    a. EXCEPTION: First three releases will be issued in a ~3 month
>>    interval.
>>    b. Exact dates must be set for each release.
>
> <SNIP>
>
> Release process proposal V2 (with few open items)

(I'd change the subject to say it's a V2)

>
> 1. oVirt will issue a new release every 6 months.
>    a. EXCEPTION: First three releases will be issued in a ~3 month interval.
>    b. Exact dates must be set for each release.
>
> 2. A week after the n-1 release is out, a release criteria for the new release should be discussed.
>    a. Release criteria will include MUST items and SHOULD items (held in wiki)
>      + MUST items will DELAY the release in any case.
>      + SHOULD items will include less critical flows and new features.
>      + SHOULD items will be handled as "best-effort" by component owners

there is a difference between defining quality goals and PRD-like 
(feature) goals.
what could be a MUST here?

>    b. Component owners (e.g. Node, engine-core, vdsm) must ACK the criteria suggested.
>    c. Release criteria discussions shouldn't take more then 2 weeks

s/then/than/

>    d. Progress on MUST items should be review every month, during the weekly meeting

s/review/reviewed/
and? I'm not sure there is a lot to be done other than to revisit with 
owner / un-must them?

>
> 3. Discuses the new version number according to the release criteria/amount of features.
>    a. Versions will be handled by each component.
>    b. The general oVirt version will the engine version.
>
> 5. 60 Days before release - Feature freeze
>    a. EXCEPTION: 30 days for 3 month release cycle
>    b. All component owners must create a new versioned branch

I don't see why this is a must, as long as they can specify the version 
to be used (i.e., it could be an existing released version or an already 
existing branch created prior to this date).

>    c. "Beta" version should be supplied immediately after.
>      + And on a nightly basis afterwards.

a nightly beta? I wouldn't call a nightly build a beta, just a nightly 
build of the branch.

>    d. Stabilization efforts should start on the new builds.
>    e. Cherry-pick fixes for high priority bugs.
>      + Zero/Minimal changes to user interface.
>      + Inform in advance on any user interface change, and any API change.
>    f. At this stage, we should start working on the release notes.
>
> 6. 30 days before release - release candidate
>    a. EXCEPTION: 15 days for 3 month release cycle
>    b. If no blockers (MUST violations) are found the last release candidate automatically becomes the final release.
>      + Rebuild without the "RC" string.
>      + ANOTHER OPTION- Avoid "Beta" or "RC" strings, just use major.minor.micro, and bump the micro every time needed.
>    c. Release manager will create a wiki with list of release blockers
>    d. Only release blockers should be fixed in this stage.
>    e. OPTIONAL: final release requires three +1 from community members
>      + This item is currently optional, I'm not sure what a +1 means (does a +1 means "I tested this release", or "This release generally looks fine for me"?)
>
> 7. Create a new RC if needed
>    a. There must be at least one week between the last release candidate and the final release
>    b. Go/No go meetings will happen once a week in this stage.
>      + Increase the amount of meeting according to the release manager decision.
>      + Release manager will inform the community on any delay.
>
> 8. Release
>   a. Create ANNOUNCE message few days before actual release.
>   b. Move all release candidate sources/binaries into the "stable" directory
>   c. Encourage community members to blog / tweet about the release
>   d. PARTY
>
> Have any comments? ideas? share them with the list!
>
> Thanks,
> Ofer Schreiber.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch