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