Forum .LRN Q&A: Install Documentation and Recomendations for dotLRN 1.0
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?
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" ?
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.
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 ...
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.
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.
I am doing something similar for University of Sydney and I was planning exactly what you said.
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.
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.
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.
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.
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.
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
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.
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.