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

[Mike Burns]

On Fri, 2013-01-11 at 14:09 -0500, Perry Myers wrote:
> 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

In general, I completely agree with Alon that we should be doing tarball
releases only and have distros handle packaging for their own distro.
It's something I'll push strongly for during the next release.

For this particular release, since we made a decision (right or wrong)
to support F18 only, I think we should at least make sure that F18 is
released prior to our release.  If we were also supporting F17, then I
would completely agree that the F18 schedule should have no impact on
our schedule.  The plan that was decided on months ago was that we were
going to concentrate on F18 only.  There weren't enough people to handle
both F17 and F18 at the time.  

As for splitting oVirt Node out and make it a completely separate
project with a different cadence, that is something I could agree with.
I think we do need to make sure that there is a *working* ovirt-node iso
image available at oVirt release, but having an ovirt-node tarball that
releases with and oVirt release doesn't necessarily need to be required.



Mike