Re: [Engine-devel] [vdsm] upstream/downstream compat
On Fri, Apr 06, 2012 at 09:58:09AM -0500, Ryan Harper wrote:
I've submitted some changes to start some of the work of removing
the
RHEV/RHEVM names throughout the vdsm code. In one of the patches,
there's a good discussion on compatibility with downstream[1]
And I wanted to continue that on the mailing list so we could have more
eyes; it's not clear to me if everyone is able to see/participate in an
inline thread to just one of my patches.
To the point; as we look at moving toward an upstream vdsm which may be
used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
driving actions. I'm interested in hearing details what our
requirements for compatibility are and which parts of the tree might be
affected.
I'd like to posit that downstream compat is the responsibility of the
distro versus the upstream community; though that's not a license to
make things difficult. IMHO, this means we can do things that help
clean up the code or move the project in a particular direction without
having to always worry about what the package looks like in a particular
distro.
Blissful upstream development is great for upstream maintainer (me), but
it leads to serious headaches for downstream maintainer with
considerable installed base (me). We have a lot of Fedoraisms and
RHELisms and RHEVisms in our code. Removing them is noble, probably
legally required, and I truly thank whomever cleans up the code. But
since there are so many of them, blind removal can add significant
burden on yours truly and his colleagues.
I would like to ask upstream to think twice before breaking downstream
compatibility. Downstream can always revert your patch, but let's make
it easier on them^Wus - have a configurable value, so that downstream
patch is a oneliner, for example. If an API must be broken, let's file a
bug on the adjacent component, so as not to surprise it.
So please, worry about how the package would look in particular distros
with considerable installed base. Discuss upgrade paths. Help make Vdsm
easily downstreamable.
The other aspect to compatibility I'd like to hear details/discussion on
the interfaces (explicit or implicit) between vdsm and ovirt-engine.
I rekindled a discussion[2] on at least one known issue around engine
including the qemu machine type in the database; Any pointers to other
places would be helpful as I'm wrapping my head around the back and
forth between vdsm and engine.
1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py
2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com