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

[Ryan Harper]

* Dan Kenigsberg <danken at redhat.com> [2012-04-21 15:38]:
> On Mon, Apr 09, 2012 at 07:25:24AM -0500, Ryan Harper wrote:
> > * 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!
> 
> I thought that I've provided some details, or more exactly, examples.
> Essentially, any patch that strips off trademarks, would have to be
> reverted downstream. I am asking (gently) to help make this reversal simple,
> hopefully a one-liner in a config file (or configure.ac).

OK

> 
> As a bad example look at vdsm_reg/engine.py. We replaced any visible
> reference to "RHEV-M" with "oVirt Engine". Now we need a multiline patch
> downstream to put it back. It would be much nicer to have a constant in
> that module, say ENGINE_NAME. When such a patch is upstream, downstream
> can touch only the constant's values.

It'll end up being case-by-case, as you've got RHEV, RHEVM and other
variants embedded in comments, constants and code; so it's not always
clear (to me) which items (save the comments) are related to the API
contract with RHEVM/engine.

Let's see how much we can get out of a top-level constant.


> 
> I also prefer topical patches, not file-based. A patch removing
> non-functional RHEV label can be pushed immediately. The famous
> http://gerrit.ovirt.org/#patch,sidebyside,3287,1,vds_bootstrap/vds_bootstrap.py
> combines both comment and an API change.

Sure, I was hoping to keep each of the patches small; and it wasn't
clear to me that the string emitted was part of the API.

I'm thinking I can to the following topical passes across the repo:

1. comments
2. variable names
3. emitted strings/values


> 
> Regards,
> Dan.

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