Release process proposal

[Ryan Harper]

* Ofer Schreiber <oschreib at redhat.com> [2012-02-16 09:30]:
> 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.
>   a. Release criteria will include MUST items and SHOULD items (held in wiki)
>     + MUST items will DELAY the release in any case.

Maybe there might be some review during development phase to determine
if the MUST items are still MUST?  

Thinking back to the issues which delayed the last release a bit; were
all of those MUST?  and if not, then we may find that we have other
items that aren't MUST, and we choose to delay release.



>     + SHOULD items will include less critical flows and new features.
>     + 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.
> 
> 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.
>     + Zero/Minimal changes to user interface.
>     + 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.
>   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
>  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

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com