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

[Joshua M. Ferraro]

----- Mike Rylander <mrylander at gmail.com> wrote:
> On 12/17/06, Joshua M. Ferraro <jmf at liblime.com> wrote:
> 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?
No ... that's not our intention at all. In fact, most of the libraries
we support handle those changes themselves (quite trivial as they are
implemented as system preferences in Koha).

> 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.
Flexibility is key to sustainability of the project IMO. My customers
want to be able to adjust their logo, stylesheets, templates, and circ
rules without calling the help desk.

Over the past few years working on Koha, I've found that the best way 
to handle 'superficial' changes is not in the core code, but in 
user-driven tasks that survive an upgrade. In Koha we have an 
administration module that allows users to specify system preferences,
issuing rules, define branches and branch relationships, update 
itemtypes, define MARC definitions, link to authorities and authorized 
values for the cataloging client, etc. The templates, for the most part,
don't contain application logic, but are merely presentation ... and 
the stylesheets control layout and color. There are even custom blocks
where the user can insert HTML, JS, or CSS.

Except for translations of the templates, which are imported/exported
by a 'gettext' script, all a library's local variations are stored in
the database. The strength of this approach for superficial changes is 
that when the code is updated, there's no need to merge anything.

So to the extent that EG doesn't currently support that flexibility,
we'd (meaning LibLime) would like to assist. Our intent is certainly
not to apply superficial changes to EG and let GPLS do all the heavy
lifting. We're looking to support a user-driven economy for EG, where
libraries other than GPLS can contribute with sponsored development
that doesn't get lost in their local installation. In fact, we've
turned away work in the past because a library wasn't willing to
sponsor the 'giving back' part of our development process. Our
current policy regarding Koha development is 'if it can't be
distributed via Koha proper, we won't do it'.

> 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.
Just to be clear, I'm not asking for commit rights to EG's CVS. I was
merely raising the question because I think it's important for the
community to discuss this topic.

Submitting patches is, I agree, a fine way to proceed for now. 
However, if/when another two to three person development team 
starts working on EG there is going to be an enormous amount 
of overhead between the 5-6 people maintaining two separate 
repositories. The reason it works for the Linux Kernel and Postgres
is, as I said before, those are HUGE development communities. Heck, 
they've got people who's sole job is to merge code. Is GPLS willing
to devote significant resources to code merging if the need arose?

The Koha community, and at least at the time being, the EG community,
are small (dozens of developers rather than hundreds or thousands).
As a result, it may make practical sense to take a more open approach
to revision control as the community grows. I completely understand the
need to manage quality control, and that is a clear strength of the
kernel/postgres approach.

> 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.
Ahh, ok, didn't realize that. But whether or not you have revision
control, the production system that PINES is running is different
than EG proper, which was my main point. As more libraries begin
using EG, they will have drastically different needs (if libraries
are one thing, they are diverse ... ) -- we'll want to make sure that 
the project isn't losing huge chunks of development work because
'outside' developers perceive the project as projecting an 'our code
vs. your code' approach. I think we want them to perceive the process
as smooth, and the core development teams working to understand 
their requirements and help them to get to know the project's coding
guidelines, processes, etc.

> 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.
The bottom line is that any development effort at LibLime will always
use revision control -- it's part of our development process. In fact,
we do revision control on production systems as well which helps our
team track tweaks made to a running system. So we always maintain what 
amounts to a fork of the codebase -- for every installation. It won't
be any different with EG.

I think the suggested approach is fine and gives us a starting
place for contributions. It would be useful to revisit it from time
to time as the community grows, but I'm perfectly happy to drop it.

So ... how about that installation process :-)

Cheers,

-- 
Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS