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. From what I have seen, you have to have a reference in the main repo pointing to the sub-module, including correct version. This would mean every update to the sub-module would also require an update to the server repo, which is easy enough, but feels like something that would easily be missed. Maybe this is easier than I think, perhaps someone else can clear that up for me. Also, if there are issues I did not outline above, please speak up so we can consider those as well. -j
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. From what I > have seen, you have to have a reference in the main repo pointing to the > sub-module, including correct version. This would mean every update to > the sub-module would also require an update to the server repo, which is > easy enough, but feels like something that would easily be missed. Maybe > this is easier than I think, perhaps someone else can clear that up for > me. Also, if there are issues I did not outline above, please speak up > so we can consider those as well.I think the best solution would be to keep their code out of our repository and instead package them as separate RPMs and then depend on them from ours. As an example, look at how we require rubygem-cobbler and rubygem-activeldap. Neither is kept in our repository. How many dependencies do we have? - -- Darryl L. Pierce <dpierce at redhat.com> : GPG KEYID: 6C4E7F1B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkkAoNMACgkQjaT4DmxOfxvvLQCg82f4No1ZWZ7ZPticVZyz6zI0 YMAAnjENKEVDWcAJlXT+s7mPKnIltesX =fMUb -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: dpierce.vcf Type: text/x-vcard Size: 319 bytes Desc: not available URL: <http://listman.redhat.com/archives/ovirt-devel/attachments/20081023/e53d35b1/attachment.vcf>
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