----- 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/arch > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
