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?
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?
+ 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?
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' ?
+ 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.
Also, what about API changes?
+ 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'.
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.
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
