Release process proposal

[Jon Choate]

----- Original Message -----
> From: "Ofer Schreiber" <oschreib at redhat.com>
> To: arch at ovirt.org
> Sent: Thursday, February 16, 2012 8:15:54 AM
> Subject: Release process proposal
> 
> 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.
>     + 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



This seems very arbitrary. If we do this, what does a major or minor version signify? Just the passage of time?



>   b. Versions will be handled by each component.
>   c. The general oVirt version will the engine version.
> 
> 5. 60 Days before release - Feature freeze



So we estimate that 1/3 of our development efforts need to go into bug fixing and stabilization?
That seems REALLY high.  If it takes two months to stabilize a release of oVirt I think we need
to take a look at our code quality and development processes.



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



Shouldn't we be working on the release notes throughout the development cycle?



> 
> 6. 30 days before release - release candidate
>   a. If no serious issues are found the last release candidate
>   automatically becomes the final release.

So there will not be the traditional vote requiring 3 acks to approve a 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.


a1. Encourage everyone to blog / tweet about the 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
>