----- Original Message ----- > From: "Ofer Schreiber" <[email protected]> > To: [email protected] > 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? > 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. > 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? > > 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? > 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 > 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
