Release process proposal

[Ofer Schreiber]

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

Will add that to v2 proposal

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

Sure, depends on their importance.
just to clarify, we're not deciding about new feature, that's up to the community/component owners, we're just agreed which feature is important enough to be a MUST.
if a feature is missing, it should be discussed with the relevant mailing list.

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

Sound like an important part of the release criteria (e.g. MUST - No data corruption bugs in "MUST" flows).

If something is not a blocker, so we won't block the release, unless we will discuss it, and decide this item is a MUST, and we forgot it during the release criteria preparation.


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

Release blockers for sure.
Probably best effort on "High" importance bugs.

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

That's under "Minimal"

> Also, what about API changes?

Same. If it's really necessary, fix it.
if not, don't put the whole release in risk just because a certain API doesn't look good enough.

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

blockers (violets MUST items in release criteria)

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

Probably wait, depends on the importance (should be discussed)


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