[Engine-devel] [vdsm] upstream/downstream compat

[Ryan Harper]

* Dan Kenigsberg <danken at redhat.com> [2012-04-09 04:21]:
> 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.

Indeed, I wasn't suggesting we just completely ignore downstream, and I
think since you're both upstream and downstream maintainer you have
valuable insight on how best to make these changes.  Looking forward to
hearing details on how best to make upstream progress while retaining
downstream compat!



> 
> > 
> > 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 at us.ibm.com

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com