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?
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?
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).
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.
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
