On Mon, Apr 09, 2012 at 07:25:24AM -0500, Ryan Harper wrote: > * Dan Kenigsberg <dan...@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. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel