Forum .LRN Q&A: Install Documentation and Recomendations for dotLRN 1.0

1: Install Documentation and Recomendations for dotLRN 1.0

Posted by Carl Robert Blesius on 01/13/03 02:45 PM

Now that there is a 4.6 release to build on what is going to be the recommended installation and implementation path for a dotLRN 1.0 installation?

We are getting ready to setup Heidelbergs first "official" dotLRN 1.0 test server as we plan for the dotLRN 1.1 release and it is not clear to me what the best way to do so will be.

Tomorrow morning I am meeting with people in our computer center to discuss the installation so we can have a local demo server running by sometime that afternoon (if all goes well).

Can someone make some recomendations here?

4.6 branch using cvs?
4.6 tarball?

Seeing that we are setting up this server before the official 1.0 release cvs is probably the answer, but that is not going to be the standard way to install dotLRN right? Would using the tarball assist in testing and documentation? Do Collaboraid's test servers ( http://dotlrn.collaboraid.net/test/ ) remove the need for this? Is there going to be a "dotLRN 1.0 tarball" ?

2: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Malte Sussdorff on 01/13/03 03:12 PM

Wouldn't it be nice to have a nightly tarball that contains OpenACS-4.6 and all the modules that you need to run dotLRN, checking out oacs-4-6 and dotlrn-1 (or whatever that tag was again).

Other than that we do need an easy installation method, e.g. use an RPM for installing with a preloaded datamodell for Postgres.

Well, this is what I'd have in mind:

- AOLserver RPM that installs itself in /usr/local/aolserver with all the necessary modules compiled. A startup file for running the dotLRN installation on http://127.0.0.1:8000 included in /etc/aolserver (or wherever)
- OpenACS RPM that contains the code, to be installed into /web/dotlrn (or wherever). Furthermore it contains Postgres / Oracle dumpfile. It would create the Oracle tablespace and load the dumpfile into this tablespace.

I'm not even sure it is feasible, let alone do I know how to do it, but you can always have dreams.

3: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Ola Hansson on 01/13/03 03:47 PM

Carl,

Now that there is a 4.6 release to build on, may I suggest 4.7 from cvs HEAD ...

Especially since you say it is a *test* server I would recommend 4.7. I for one would love to benefit from all the new code that is literally flowing in to HEAD. Also, if you are on PostgreSQL, keep in mind that 7.3.1 won't work on 4.6.

There is probably not much difference between choosing 4.6 cvs and the tarball, assuming no more code will go into this release. But, grabbing the code from cvs is almost always nicer, IMHO, because it makes it so much easier to *ahem* cvs update. 😊

Ah! And don't forget; the i18n stuff is only on 4.7. To me, that alone is reason enough to go this route.

Then again, I'm just a web nerd, who wants the latest of everything ...

/Ola

4: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 3)

Posted by Jeff Davis on 01/13/03 04:00 PM

I am planning to maintain 4.6 on an ongoing basis (rolling bugfixes back from the head and incorporating new modules). To that end, I am hoping that to cut a minor version every 4-6 weeks. I run my personal site as a checkout of the 4.6 branch as well which is nice although I think for a real production site that's not a possibility since you almost certainly need your own CVS repository for managing the release process.

One thing that is not going to go into 4.6 is the i18n work (and it will not be in dotlrn 1.0 either). I know Lars has been talking about timeline for a 4.7/1.1 release that would have the full i18n work in but I am mostly concerned with getting a clean 4.6/1.0 install working for now. I would think that for Heidelberg's test server you would have to be on HEAD for both openacs and dotlrn since you definitely want to be testing with the i18n code.

5: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Janine Ohmer on 01/13/03 04:30 PM

The dotLRN 1.0 testing will be done on 4.6 - that may or may not matter since you're talking about looking ahead to 1.1, but it's a another datapoint for your decision.

6: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 4)

Posted by Carl Robert Blesius on 01/13/03 11:11 PM

We want 1.0 out as soon as possible to increase adoption of dotLRN in general. The earlier we have a clean 1.0 the sooner everyone can start to focus on 1.1 (with the i18n work and improvements). We also need a defined upgrade path. Seeing that the upgrade path for OpenACS (4.6 -> 4.7) is defined and dotLRN is just a bunch of OpenACS packages it seems logical that 4.6/1.0 -> 4.7/1.1 is the defined path.

We will obviously be running/testing/pushing 1.1 in Heidelberg. The server I am talking about here is more of a "get to know" dotLRN server for early adopters and local demos. We are tending towards 4.6/1.0 for this to help push 1.0 out the door and keep errors to a minimum for our early users (first impressions are important).

So the answer to my question is probably:

Use cvs based on the 4.6 branch if we want to start using dotLRN 1.0 now (updating it using cvs as needed). This way we will eventually have a local "clean 4.6/1.0 tarball" equivalent as general 1.0 testing and release progresses. I just hope that the update process using cvs (4.6 branch) isn't a bugger.

7: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Rafael Calvo on 01/15/03 04:07 AM

Carl,
I am doing something similar for University of Sydney and I was planning exactly what you said.

cheers

8: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 6)

Posted by John Norman on 01/18/03 01:55 PM

First impressions are vital. We missed out on a major opportunity when we were showing people latest code from cvs head - too much broke and the impression was created that dotLRN is unreliable, flaky software. We are recovering slowly from this after help from the team at Sloan. People here are willing to be told this is what we can do today and this is what we expect to do tomorrow (that's already better than you can get from Blackboard). But the bit you offer today *must* be rock solid.

Failing to give due weight to this would restrict distribution to enthusiasts and dotLRN will not reach the mainstream.

Blackboard has had 2 minor glitches in 15 months of running here. This is the sort of reliability you will need.

9: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 8)

Posted by Bart Teeuwisse on 01/23/03 02:58 PM

John,

come help dotLRN reach the stability you seek by joining in the dotLRN 1.0 testing efforts. Subscribe to the dotLRN testing forum (https://openacs.org/forums/forum-view?forum_id=66604) to stay informed. Or contact me directly if you have resources to offer like servers or man power.

We could use your help.

/Bart

10: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Don Baccus on 01/25/03 11:04 PM

Hey John, could you give me some data on how reliable Blackboard was BEFORE IT WAS RELEASED????

Comparing the stability of a piece of software that's been available for quite a long time with a PRE-RELEASE piece of software like dotLRN is really unfair.

If you can't deal with the instability of PRE-RELEASE software ... don't use it. This advice is sound whether you're looking at closed-source, proprietary software or open source software like dotLRN.

Of course we know it has to be reliable. That's why - as Bart mentions - we are organizing testers. That's why we have a bugtracker. That's why I spent much of last week doing scalability testing and working up potential solutions for one of the problems I found.

CVS HEAD is a bit unstable at the moment because there's a lot of work underway to add localization to OpenACS and dotLRN. The folks involved made it clear that the effort would upset the apple cart for a bit - that's why we made a CVS branch for dotLRN 1.0 beforehand. The first release of dotLRN won't be coming from CVS HEAD, but rather bug fixes made against the 1.0 branch. The code you've tried to use won't be released until dotLRN 1.1.

11: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by John Norman on 01/26/03 08:42 AM

I'm sorry if my post seemed unfair Don. I have a lot of admiration for what this group is doing. I was reacting mostly to Ola's post suggesting that 4.7 from CVS head should be used to set up the server for a test installation of dotLRN 1.0. I imagined the test to be about - lets see what this software can do for us rather than lets find our the latest bugs. We were frustrated by such advice late last year because 4.5 from head (before you adopted 4.6 for the next version) and dotLRN 1.0 from head almost never seemed to be a working combination (we tried every couple of days for about 2 weeks and different things were broken each time). I was telling everyone how great your software was and ended up with egg on my face because I couldn't make it run fully.

I understand that a great deal was in flux at the time, but some attention could have been given to tagging a working combination in cvs so newcomers wishing to try something out could go for that.

The only sense in which the comparison is fair is the number of posts I see saying things like - we should aim to pick off WebCT users.

I want you to succeed and I apologise if I caused offense.

12: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by John Norman on 01/26/03 08:46 AM

BTW we also volutneered for OpenACS 4.6 testing and dotLRN 1.0 testing (before Bart's post)

13: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Janine Ohmer on 01/26/03 10:34 PM

John,

Generally the "something" tagged for newcomers to try out is the beta release. Until a release reaches beta status, it's not for use by the faint of heart, or those giving demos. If someone suggested using CVS HEAD for serious work, they were mistaken.

Besides, as someone who has given a few demos in her time I can assure you that even with packaged software from big-name companies it's always a good idea to run through your demo *before* you present anything to an audience, especially if that audience is predisposed to be skeptical. You never know what gremlins you may uncover, or just things that don't work quite the way you thought they would.

14: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Samir Joshi on 01/31/03 08:24 AM

Two quick questions -

1) What will be major difference between dotLRN 1.1 and 1.0 apart from Internationalization ? Or is it so that 1.1 will be on community radar only after 1.0 release as Carl suggests above.

2) For dotLRN 1.0, should we be using OpenACS 4.6.1 (instead of 4.6) as announced here : https://openacs.org/forums/message-view?message_id=75519

-Samir

15: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 1)

Posted by Janine Ohmer on 01/31/03 05:46 PM

Samir,

We haven't formally decided what goes into dotLRN 1.1 yet, at least not as far as I know. My hunch is that i18n will be such a big deal that it may well get its own release, which would probably be 1.1. Right now we're totally focused on getting 1.0 done.

I believe 4.6.1 will be the new base for dotLRN when it's released, but since it's still under construction you use at your own risk right now.

16: Re: Install Documentation and Recomendations for dotLRN 1.0 (response to 5)

Posted by Bart Teeuwisse on 01/31/03 06:10 PM

DotLRN testing will indeed be done on 4.6 and dotLRN 1.0. I'm working on setting up a couple of test servers based on the CVS versions of these branches. See the dotLRN documentation for installation instructions if you'd like setup your own server.

The test servers will be updated on a regular basis with fresh checkouts from CVS. That means that all work on the future OpenACS 4.6.1 release will be included.

/Bart