[OPEN-ILS-DEV] Getting there -- bootstrapping OpenSRF Client problem

[Mike Rylander]

On 12/17/06, Joshua M. Ferraro <jmf at liblime.com> wrote:
> I was mainly just fishing for the answer to the question 'how will
> the core EG developers handle code contributions?'. The answer just
> informs what LibLime's (and any other contributor's) development
> environment's going to look like (ie, we all need _some_ revision
> control system, @open-ils.org, or not ).

Well, then let's all get on the same page with our intentions on the
table without any more "fishing" expeditions.

Are you saying that you need to keep a full local copy of the EG
codebase (which will drift -- bad for you) in a local repository so
that you can make local customizations to things like logos and basic
templates?  And is this opposed to simply grabbing the latest
version-stamped tarball and creating a differential subset?

I won't presume to tell you how to fulfill your customer's needs, but
perhaps you're underestimating the flexibility of EG overall.  AFAICT,
all you should need to deal with are superficial elements (as far as
the code is concerned) such as template tweaks, local
circulation/hold/ingest setup, and configuration files.  If you don't
see this as the case, then please share some details.  Perhaps we can
all learn something here and make EG better for all.

If I'm misunderstanding your intended use for a "local repository"
(entirely possible, since you haven't stated why it's necessary) and
you're talking about direct development effort as opposed to customer
customizations, then, well, I still don't get why you need this.  I
mean (in a nutshell), you submit a proposal for everyone to comment
on, get feedback, check out the code, develop against it and then
submit the patch.

The first step, of course, is to install the system and become
familiar with the architecture and code -- both functionally and
stylisticly.  If there is some particular and strong reasons why,
after having done this, you don't see this idea as viable at all we
would love to hear why.  Perhaps we can all work together to fix the
issues, or, in the alternative, you may be able to convince us that
another option is a better choice at this time.

> I'm also fine with maintaining a LibLime EG version control system (as
> I'm sure GPLS does for production EG).

Actually, you'd be wrong about that.  PINES runs on the code you see
in CVS (the rel_1_0 branch), with the ONLY difference being the site
specific configuration files that define IP addresses, database setup
and the like, and the delay of some staff client additions due to
testing requirements.  That's eating our own dog food.

Obviously, local updates to templates and such should be retained on
upgrade, and that will be part of the proposal I will be introducing
for installation and deployment.  To state unequivocally that you will
need to keep what amounts to a full fork in order to do any work seems
a bit hyperbolic, IMHO.

Lastly, I certainly don't want to sound dictatorial or to issue any
ultimatums, and it is not the intention of GPLS (or myself) to stymie
the growth of any component of this fledgling community, but I think
we're really going to need more detailed thoughts on these issues if
you expect us to understand why all this is a requirement for you,
Josh.

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org