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