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

[Dan Kenigsberg]

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).

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.

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.

Regards,
Dan.