Hello Dan, Just thought I'd add that I have borrowed a few things from your OPAC skin in ILS-Contrib, so thanks for making it available. It's been really nice having somebody at least one step ahead of us so far.
Dan >>> On 1/20/2010 at 2:52 PM, Dan Scott <[email protected]> wrote: > On Wed, 2010-01-20 at 13:51 -0500, Joe Atzberger wrote: >> Dan, >> >> >> This sounds like a good case for a DVCS, allowing you to have your >> changes more in-stream than in-parallel. Now that they are >> available, have you considered using a either the launchpad or github >> repos as a starting point? > > Not really. It's been working well enough for us, for the limited number > of times we've gone through the complete process (twice, I think), so > it's hard to justify throwing effort into a different direction. We went > with ILS-Contrib from the beginning in the hopes that our work might be > reusable by others who had the same needs that we do, and at the time > that was the only publicized repository (and effectively it still is the > only publicized repo). > > Even if we did move to a DVCS, though, I'm not sure it would change how > we handle rolling out our skins. We certainly wouldn't want to duplicate > all of the files for each skin in the DVCS. > >> Upsides: lighter weight, less maintenance having to duplicate updates >> in parallel, your changes would live upstream from the your production >> install, and you could easily switch back and forth w/ stock code. >> > > I dunno about lighter weight or less maintenance. It's not like we're > updating our production site (or even our test server) every day, and > we're only talking about a handful of files. > >> Downsides: conversion, possible mirror latency, new tools. > > Well, I'm familiar with bzr, so no downside if we went that route, and > the six-hour or so latency of Launchpad doesn't bother me given how > rarely we do a complete update of our production or test sites. > >> I suppose if you aren't doing it though, than probably nobody is yet. >> But as far as documentation goes, it might be better for us to >> outline the process of maintaining customizations w/ DVCS so as to >> have everything under one paradigm that's a little more portable, >> durable and likely to succeed. > > I definitely agree that this would be valuable, and if somebody (else) > makes it an easy path to follow then I'll be second in line :)
