rebasing for oVirt 3.3.1?

[Dan Kenigsberg]

On Mon, Sep 09, 2013 at 03:17:35PM +0300, Itamar Heim wrote:
> with 3.3.0 coming soon, one of the questions I heard is "what about
> 3.3.1" considering the number of patches fox bugs that went into
> master branch since since we branched to stabilize 3.3.0.
> i.e., most of the work in master branch has been focused on bug fixes)
> 
> so my suggestion is for 3.3.1 that we rebase from master, then move
> to backporting patches to that branch for the rest of 3.3 time
> frame.
> 
> while this poses a small risk, i believe its the best course forward
> to making ovirt 3.3 a more robust and stable version going forward.
> 
> this is mostly about ovirt-engine, and probably vdsm. for the other
> projects, its up to the maintainer, based on risk/benefit.

To make this happen for Vdsm, we need to slow things down a bit,
stabilize what we have, and test it out.

Most of our work since ovirt-3.3 was bug fixing (23 patches), but some
of the 101 patches we've got are related to refactoring (19), cleanups
(27), test improvements (21), behind-the-scenes features (6), and
visible features (5). 

Refactoring included Zhou Zheng Sheng's Ubuntu-readiness patches, which
may still incur surprises to sysV/systemd/upstart service framework, and
changes to how network configurators are to be used.

Behind-the-scenes features include speedup to block-based storage:
- One shot teardown.
- Avoid Img and Vol produces in fileVolume.getV*Size
- Make lvm.listPVNames() be based on vgs information.
- One shot prepare.
- Introduce lvm short filters.

Visible features are few, and only one of them:
- clientIF: automatically unpause vms in EIO when SD becomes active
carries some kind of a risk to a timely release. The rest of them are:
- Support for multiple heads for Qxl display device
- Add support for direct setting of cpu_shares when creating a VM
- Introducing hidden_vlans configurable.
- macspoof hooks: new hook script to enable macspoof filtering per vnic.

I think we can release vdsm-4.13.0 within a week if we put a hold on new
features and big changes, and put enough effort into testing the
mostly-changed areas:
- service framework
- VM lifecycle over block storage (including auto unpause)
- network configuration

Then, we could release vdsm-4.13.z without risking the stability of
ovirt-3.3.1.

Let's do it!

Dan.