Release process proposal

[Yaniv Kaul]

On 02/16/2012 03:15 PM, Ofer Schreiber wrote:
> 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.
>
> 2. A week after the n-1 release is out, a release criteria for the new release should be discussed.

discussed is fine, what is the ETA of a decision?

>    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.

So (major) new features are decided and agreed upon (and documented) on 
the release criteria?

>      + SHOULD items will be handled as "best-effort" by component owners
>    b. Component owners (e.g. Node, engine-core, vdsm) must ACK the criteria suggested.

What about general items? For example: no data corruption bugs, no known 
security issues, etc.?
More interestingly, what about the ugly, hairy bugs, which are not 
blockers, just gooey?

>
> 3. OPTIONAL: Discuses the new version number according to the release criteria/amount of features.
>    a. OR BETTER: Increase MAJOR version every second release
>    b. Versions will be handled by each component.
>    c. The general oVirt version will the engine version.
>
> 5. 60 Days before release - Feature freeze
>    a. All component owners must create a new versioned branch
>    b. "Beta" version should be supplied immediately after.
>      + And on a nightly basis afterwards.
>    c. Stabilization efforts should start on the new builds.
>    d. Cherry-pick fixes for important issues only.

What is 'important' ?

>      + Zero/Minimal changes to user interface.

Unless the UI sucks, of course. If we get feedback it's wrong, we should 
change. Been known to happen before.
Also, what about API changes?

>      + Inform in advance on any user interface change.
>    e. At this stage, we should start working on the release notes.
>
> 6. 30 days before release - release candidate
>    a. If no serious issues are found the last release candidate automatically becomes the final release.

Define 'serious'.

>    b. Release manager will create a wiki with list of release blockers
>    c. Only release blockers should be fixed in this stage.
>
> 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

Do we expect to release all components together? For example, what if we 
found a blocker in component X, and component Y is fine and dandy? it'll 
just wait?
Y.

>   a. Create ANNOUNCE message few days before actual release.
>   b. 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