[OPEN-ILS-DEV] import data from voyager - wiki documentation

[Mike Rylander]

On 5/26/07, Larry Page <larryspage at gmail.com> wrote:
> Dan,
>
> I believe it is good that you are enjoying open source and Evergreen. You
> mentioned you would like to help me for the installation. I appreciate but I
> already successfully installed on the Debian Etch according to the
> documentation: Installing Evergreen on Ubuntu 7.04 with some changes. It is
> a very good document. Thank dbw2 for doing this great job. In the mean time,
> I respect all the people like Scott McKellar, Mike Rylander, Don McMorris
> and many others. They really make contributions to the community with their
> knowledge and / or experience.
>
> Look at the archive. You did replied one of my post. But you made me
> confused and I finally found you were not corrected. See the following your
> post:
>  ======================================================
>
> On 16/05/07, Larry Page <larryspage at gmail.com> wrote:
> > Hi,
> >
> > After I installed Evergreen version 1.1.5, I found there is no opensrf_all
> > openils_all evergreen_core created. Are these files obsolete in this
> > version, or something wrong with building files? But I could not seen any
> > error message about it.
> >
> > Thanks
> >
> >
> >
>
> Hi Larry:
>
> When you specify "openils_all opensrf_all evergreen_core", you're
> actually saying "make all of the pieces of openils, and all of the
> pieces of opensrf, and just the core of evergreen" - that is, these
> are abstract targets, not actual files that you're trying to build.
>
> If you don't see error messages, that's probably a very good thing.
> How does "make install" go for you?
>
> Dan Scott
> Laurentian University
> ==============================================================
> In reality, there is a file: /openils/bin/opensrf_all for Evergreen v1.0.x
> but it is not appeared in Evergreen v1.1.5. Luckly, the updated
> documentation: Installing Evergreen on Ubuntu 7.04, section 23: Setting up
> Evergreen has this updade and now it clearly mentions the difference among
> those versions.
>

Actually, in reality there has never been a file called openils_all
nor one called evergreen_all in any version of the software.  However,
all three have nearly always been top level make targets, and so when
you listed all three the obvious assumption, lacking any further
clarification from you, was that you were trying to discuss these make
targets.  This assumption was then followed up by a request for the
status of your build, all else being equal.

While I understand that you are not particularly familiar with the
software, it is quite unreasonable to require that others decide which
of the qualifiers to your request are conflating factors, such as
listing several well known make targets when you meant to list a
single utility script.

Dan's response to your message seems quite sane to me, and shows, in
fact, a good understanding of the build and install process.

> Dan, thanks again for the suggestion the read the Open-ILS Blog. Although it
> is pretty long but I will try. For your kindness, I would also like to give
> you some recommendation. I have not got time to read all the posts, just

Dan's recommendation that you attempt to understand the project from
the perspective of its history is, in my opinion, not only a good one,
but will be quite important if you wish to become positively involved
in the community.  I suggest you proceed with this before berating the
project or its contributors, and assuming contributors' competence
level in any given programming language.

> skimed some of them. The following is your another post on the Evergreen
> make error:
> ==============================================================
>
> > On Debian Etch, in stage: "Building and Installing the Source", after make
> > config step, I tried to make and got the error and I do not know how the
> > Bill's server pass it (make config). The error message has something like:
> >
> > /usr/include/apr-1.0/apr.h:270: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before 'apr_off_t'
>
> <snip>
>
> The problem you described here is almost certainly a mismatch of an
> Apache Portable Runtime (apr) for 2.0.x with Apache 2.2 source. You'll
> need to ensure that your apache, apache-devel, & libapr1 packages are
> all at the same level for the compile to work.
>
>
> Dan Scott
> Laurentian University
> ==============================================================
> Obviously, It is because of no define of apr_off_t --- If you had had
> knowledge of C language, you would not make this very strong but completely

And obviously hind-sight is 20-20.  We all make mistakes, Larry, much
like you listing three make targets and expecting us to know you meant
one (and only one) utility script.

First of all, library version mismatches are a completely valid (and
common) reason for a missing definitions.  Your critique fails on it's
face due to this.

However, giving you the benefit of the doubt, the actual fix for this
problem is to pass the compiler a define flag to turn on large file
support on 32bit platforms.  This is not, in fact, an obvious
conclusion that can be made based simply on knowledge of the C
language, as you assert, but requires (and did require to solve)
digging into the source for APR as well as the system headers.

> wrong assertion. If there is a computer science department in Laurentian
> University, I would recommend you go to take some courses to brush your
> skills. To help others, knowledge is much more important than passion.
> Lacking of knowledge, things may be even worse if you try to do.
>

And this ... well ... this is just plain rude, and will not be
tolerated on-list.  As one of the administrators for this list, as
well as the general list, I ask -- no, require -- that you refrain
from personal attacks against any other member of this list, or you
will not be welcome here.  We all welcome substantive critique of the
code we submit, but nobody should be subjected to such ridicule.

Now, you may not know who Dan Scott is or to what projects he has
contributed in the past or in fact what his background is within the
realm of computer science -- and I contend that you have shown a
severe lack of knowledge to that effect -- however, it would, in my
opinion, behoove you to follow your own advice, which follows:

> One more, discussing is welcome in any forums. However, do NOT draw a simple
> conclusion before making a doulbe check -- even ten times checks; and do NOT
> draw any conclusion if you do not have that knowledge.

Folks, I think that's the lesson from what Larry has posted here today.

--miker

>
> On 5/25/07, Dan Scott <denials at gmail.com> wrote:
> >
> > Jeroen has objected to my characterization of Larry as a troll.
> >
> > I apologize for my hasty reaction. All I can say in my defense is that
> > I just finished writing a fairly significant chunk of documentation in
> > the wiki (on importing MARC records into Evergreen) late in the
> > evening entirely on my own unpaid time, and Larry's post invoked a
> > reaction that I probably should have slept on rather than posting
> > immediately.
> >
> > So: Larry, from my perspective:
> > * I admit that I don't know what you mean by a "functional oriented
> > architecture" - I certainly have seen plenty of evidence of object
> > oriented code, interface definition language, and object-relational
> > mapping that suggests something very different. But maybe we have
> > different things in mind.
> > * I think that using a Jabber message server as the underlying
> > messaging system was actually a brilliant implementation decision that
> > underpins Evergreen's ability to flexibly scale across multiple
> > commodity servers.
> > * If you're concerned about the security of the Jabber server
> > approach, please demonstrate this vulnerability. The nice thing about
> > an open source project is that if there is, in fact, a vulnerability,
> > it will in all likellihood be rapidly addressed and if not, you have
> > the option of addressing it yourself, unlike, say, the proprietary ILS
> > I am most familiar with that passes user passwords in the clear as a
> > hidden input form variable with every Web page served.
> >
> > Suggesting that EG needs to be redesigned is pretty extreme. I
> > strongly suggest reading all of the blog entries in order in the
> > Open-ILS Blog (http://open-ils.org/blog/) to understand how EG
> > developed and the care with which design decisions were made. There
> > might be areas that need to be reconsidered, but it helps to be
> > plugged in to the conversations that have already been held.
> >
> > I do see that approximately a week ago you had a support question that
> > went unanswered, and wonder if part of your comment came from
> > frustration. If you are still looking for help with Evergreen, I will
> > try to help you out.
> >
> > Dan
> >
> > --
> > Dan Scott
> > Laurentian University
> >
>
>


-- 
Mike Rylander