[Ovirt-devel] How to handle 3rd party code?

[David Lutterkort]

On Thu, 2008-10-23 at 12:01 -0400, Jason Guiditta wrote:
> I have been meaning to send an email to the list about this for weeks.
> I am looking to assemble a consensus on how to handle version control
> for some 3rd party code we are using in the server suite.  These are,
> for the moment at least, rails plugins (not necessarily available as
> gems or rpms) and javascript libraries/plugins.  There are a couple of
> issues we need to solve here:
> 1) Keeping up to date on these bits of code, which may or may not be
> available in git (a lot of the javascript is hosted in svn, some no
> version control at all)
> 2) We may have our own patches that we need to carry, though of course
> we will try to push them upstream.
> 3) Many of these items do no follow our practices- specifically
> whitespace and ^Ms.  This makes it difficult to drop in the updated code
> and compare it to our (cleaned-up) version in git, especially if we have
> made any changes/customizations.
> 
> The only idea I have heard/read about that seems to be a possible good
> solution is sub-modules, but there seems to be a fair amount of
> maintenance involved in keeping them in synch with our main repo
> whenever we do an update or patch to one of the modules.

The overriding concern is that we don't want to maintain forks of all
these upstream projects; the best solution would be to approach each
upstream and ask them to take our patches, and go to a release model
that is more amenable to reuse (though if they do not do properly
versioned releases, it's fine to use e.g. svn revision numbers as a
substitute)

The question of how to package all that is secondary to that concern.
Ideally, we would have a separate RPM for each upstream, but if that's
not feasible in some cases (e.g. JS libraries, Fedora doesn't even have
JS packaging guidelines) it would be ok to pull the sources into a
ovirt-specific RPM as long as those sources do not diverge from
upstream.

As long as we follow a process of 'use pristine upstream + temporary
patches', it should be fairly easy to script the import/update of newer
upstream versions. I would put those things into a separate
'ovirt-js-modules' or similar and keep them out of the main ovirt-server
git, with the assumption that developers will install/update that RPM
separately.

To avoid problems with the directories into which those files go, we
should see if either Rails or Mongrel lets use reconfigure the location
of JS libs - Rails plugins should be less problematic, since we can
always futz with LOAD_PATH.

David