Release process proposal

[Ofer Schreiber]

----- Original Message -----
> On 02/19/2012 03:51 PM, Ofer Schreiber wrote:
> >
> > ----- Original Message -----
> >> 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.
> >
> > <SNIP>
> >
> > Release process proposal V2 (with few open items)
> 
> (I'd change the subject to say it's a V2)
> 
> >
> > 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
> 
> there is a difference between defining quality goals and PRD-like
> (feature) goals.
> what could be a MUST here?

Release criteria is absolutely not a PRD. it's the minimal criteria needed in order to release a specific version to the world.
IMO, new (big) features can be in the release criteria (only as SHOULD). I do see some value saying "This release SHOULD contain the new ovirt-engine-coffee-maker package", especially if Eli, the owner of that component really want it in the next version of oVirt, and we have users waiting for it.

> 
> >    b. Component owners (e.g. Node, engine-core, vdsm) must ACK the
> >    criteria suggested.
> >    c. Release criteria discussions shouldn't take more then 2 weeks
> 
> s/then/than/
> 
> >    d. Progress on MUST items should be review every month, during
> >    the weekly meeting
> 
> s/review/reviewed/
> and? I'm not sure there is a lot to be done other than to revisit
> with
> owner / un-must them?

un-must is one of the possibilities. it will raise the owner/community attention as well.

> 
> >
> > 3. Discuses the new version number according to the release
> > criteria/amount of features.
> >    a. Versions will be handled by each component.
> >    b. The general oVirt version will the engine version.
> >
> > 5. 60 Days before release - Feature freeze
> >    a. EXCEPTION: 30 days for 3 month release cycle
> >    b. All component owners must create a new versioned branch
> 
> I don't see why this is a must, as long as they can specify the
> version
> to be used (i.e., it could be an existing released version or an
> already
> existing branch created prior to this date).

I think branching is a must. especially during the "release candidate" phase.
What will you do with new commits (that should not get into the new version?)

(I don't care about "new" branch, just a separate one. If a specific owner doesn't want to release a new version, that's a different discussion)

> 
> >    c. "Beta" version should be supplied immediately after.
> >      + And on a nightly basis afterwards.
> 
> a nightly beta? I wouldn't call a nightly build a beta, just a
> nightly
> build of the branch.

Any suggestion about the frequency of Beta builds?
I'm not sure we want to create so many different releases (e.g - stable, beta/rc, nightly)

> 
> >    d. Stabilization efforts should start on the new builds.
> >    e. Cherry-pick fixes for high priority bugs.
> >      + Zero/Minimal changes to user interface.
> >      + Inform in advance on any user interface change, and any API
> >      change.
> >    f. At this stage, we should start working on the release notes.
> >
> > 6. 30 days before release - release candidate
> >    a. EXCEPTION: 15 days for 3 month release cycle
> >    b. If no blockers (MUST violations) are found the last release
> >    candidate automatically becomes the final release.
> >      + Rebuild without the "RC" string.
> >      + ANOTHER OPTION- Avoid "Beta" or "RC" strings, just use
> >      major.minor.micro, and bump the micro every time needed.
> >    c. Release manager will create a wiki with list of release
> >    blockers
> >    d. Only release blockers should be fixed in this stage.
> >    e. OPTIONAL: final release requires three +1 from community
> >    members
> >      + This item is currently optional, I'm not sure what a +1
> >      means (does a +1 means "I tested this release", or "This
> >      release generally looks fine for me"?)
> >
> > 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. Move all release candidate sources/binaries into the "stable"
> >   directory
> >   c. Encourage community members to blog / tweet about the release
> >   d. 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
> 
>