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

[Joshua Ferraro]

On Sat, Dec 16, 2006 at 05:18:59PM -0500, Mike Rylander wrote:
> Did you read the rest of the message after "However" or the follow up
> from Don?  If so, then I must not have explained myself properly.  The
> discussion of a plan (which may or may not include the bundles) has
> started.  There are other ways than bundles to keep CPANable
> dependencies up to date, and in many ways they are superior.
> 
> I ask you to please stop issuing updates to these for the time being.
> There's nothing anyone can do to stop you, of course, but until there
> is more discussion surrounding the way forward for easing
> installation, we will not be pointing to them from the wiki.  They are
> causing installation/documentation churn in _two_ places now (wiki and
> CPAN), and there are too many unknowns involved in blindly installing
> the latest-and-greatest of everything from CPAN via a bundle.  In
> addition, the cost/benefit ratio just doesn't make it worth the time
> to doublecheck them every time we make a commit to CVS.  Yes, I mean
> for both new and removed dependencies.
Fair enough. One footnote is that you can easily specify versions of 
modules in a bundle to force installation of that version. But
ultimately I agree that a CPAN bundle is not ideal for the reasons you
cited.

> >OK with everyone if I update the docs to mention the bundles as an
> >alternative way to install the perl mods once other prereqs have been
> >met?
> No, that's not ok.  They are not tested for use in installing
> Evergreen, and they represent a "package" attached to the project and
> would be expected to "just work" because it has a version number
> stamped on it, where as the wiki is a living document (with
> disclaimers of incompleteness where appropriate) that is expected to
> change and evolve over time.
No problem, just trying to be helpful here.

> I'm working on a full proposal for a packaging and deployment system
> (in abstract for now) that we can all work on over time but should
> provide some immediate benefit long before the entire thing is
> complete, so (all) please stay tuned for that.  I'll try to finish it
> up tonight or tomorrow morning (holiday guests are over right now, but
> I'll find some time ;) ).
I should mention that LibLime has devoted some resources to hiring an
Automake/Autoconf expert and would be glad to assist in the process of
creating a formalized plan for how to package/deploy using standard GNU
practices.

One concern I have, expressed by others as well, is that while the
project's documentation can obviously be user-contributed, there's
currently no way for developers to contribute code with revision control
without forking the repository. Are there plans to start a project
repository at a third-party host (I'd recommend Savannah), maybe even
upgrading from CVS to SVN?

LibLime has a few contributions we'd like to make to the project in the
coming months, including:

1. Automake/Autoconf
2. A Z39.50 Server
3. NCIP Support (in addition to SIP2)

Any thoughts on how best to handle revision control of the project as
a development community forms around Evergreen?

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