Release process proposal

[Ofer Schreiber]

----- Original Message -----
> 
> 
> ----- 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?

Point taken

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

I think this amount of time is necessary, especially in the scale of the oVirt project (multiple build blocks, api, features etc)

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

define "working on the the release notes".
each component owner should handle his release notes.
in this stage, we should gather all the release notes into something that looks reasonable.

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

Sounds reasonable.

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

+1

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