[vdsm] ATTN: Project Maintainers: Code Freeze/Branch/Beta Build deadlines

[Perry Myers]

On 01/11/2013 01:51 PM, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "Perry Myers" <pmyers at redhat.com>
>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>> Cc: "Mike Burns" <mburns at redhat.com>, "arch" <arch at ovirt.org>
>> Sent: Friday, January 11, 2013 7:28:29 PM
>> Subject: Re: [vdsm] ATTN: Project Maintainers: Code Freeze/Branch/Beta Build deadlines
>>
>>> Can we discuss this a little farther?
>>> Why do you think that we cannot release ovirt-3.2 before fedora-18?
>>
>> oVirt contains both Node and Engine parts
> 
> ovirt-node is totally different discussion as it is mini distribution, re-redistributing fedora and oVirt components. ovirt-node can be released in other milestones, based on the lineup of dependencies.
> 
>>
>> AIUI
>>
>> In 3.2 vdsm requires F18 version of libvirt, so if oVirt 3.2 comes
>> out
>> prior to F18, then oVirt 3.2 would require a yet unreleased version
>> of
>> Fedora to run on which is probably not a good idea
> 
> libvirt is upstream.
> oVirt is upstrema.
> Upstream oVirt requires some upstream version of libvirt at specific version of oVirt.
> 
> Downstream maintainers of oVirt will require the proper minimal version of libvirt exists in downstream for proper execution.
> Upstream maintainers do not care which version of libvirt exists in downstream, as a specific downstream is irrelevant.
> Let's say we support debian and fedora, the version of libvirt is probably different in each, do we aim to the libvirt of debian? of fedora?
> No... upstream aims for libvirt it actually requires (minimum version to provide features).
> 
>> oVirt Node (which is part of oVirt project) also requires Fedora 18,
>> since a Fedora 17 based oVirt Node would not have the required
>> version
>> of libvirt needed to support 3.2 functionality
> 
> Are you sure that the required version of libvirt cannot be run on fedora-17?
> I think we can provide (had we wanted to) ovirt-node based on fedora-17 with oVirt-3.2 with all dependencies, before fedora-18 is out, and I also believe that it would have been healthier approach.
> The fact that oVirt-3.2 requires out-of-tree libvirt on fedora-17, does not mean user cannot install the required version, this is true to any other dependency.
> The gain is large, as we take a stable platform with minimum unstable components.
> 
> What I would like is for us to start acting like pure upstream...

In that case, oVirt Node project should be removed from the oVirt
release cadence, since it cannot be decoupled from the Fedora release
cadence.

Also given that the intent is for oVirt Node to be used for multiple
other projects (oVirt Engine, Fedora OpenStack, Fedora Gluster), perhaps
it does make sense to decouple oVirt Node core from oVirt Engine
releases and treat it as a separate project from oVirt Engine with
separate release schedule.

I think this might be a good way to go.

oVirt Node core team can produce oVirt Node images on a Fedora release
cadence (6 months) and then oVirt Engine team can consume these images
and inject vdsm into them on their own release cadence.

So the release numbering like 3.1, 3.2 would only apply to the Engine
side of things, while oVirt release numbering would be tied to Fedora
release numbering.

Mike, what are your thoughts?

Perry