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. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel