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

On Mon, Apr 09, 2012 at 07:25:24AM -0500, Ryan Harper wrote: > * Dan Kenigsberg <danken(a)redhat.com&gt; [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_bootst... combines both comment and an API change.

Regards, Dan.