<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>+1 on both comments.<br><hr id="zwchr"><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
On 02/19/2012 03:51 PM, Ofer Schreiber wrote:
<blockquote cite="mid:d75d15a3-717b-40a8-8865-1aba4f3eb417@zmail14.collab.prod.int.phx2.redhat.com">
<pre>----- Original Message -----
</pre>
<blockquote>
<pre>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.
</pre>
</blockquote>
<pre><SNIP>
Release process proposal V2 (with few open items)
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.
c. Release criteria discussions shouldn't take more then 2 weeks
d. Progress on MUST items should be review every month, during the weekly meeting
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
c. "Beta" version should be supplied immediately after.
+ And on a nightly basis afterwards.
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!
</pre>
</blockquote>
please consider the following:<br>
<pre><big>-6. f.30 days before release - release candidate - Test day - i think should be part of the process
-6. g.30 days before release - dev leads/representatives from each component participation on the weekly meetings statuses</big>
</pre>
Moran.<br>
<br><br>
<br>
<blockquote cite="mid:d75d15a3-717b-40a8-8865-1aba4f3eb417@zmail14.collab.prod.int.phx2.redhat.com">
<pre>Thanks,
Ofer Schreiber.
_______________________________________________
Arch mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Arch@ovirt.org" target="_blank">Arch@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/arch" target="_blank">http://lists.ovirt.org/mailman/listinfo/arch</a>
</pre>
</blockquote>
<br>
</blockquote><br></div></body></html>