Forum .LRN Q&A: Re: .LRN release process and roadmap

3: Re: .LRN release process and roadmap (response to 2)

Posted by Tracy Adams on 04/16/04 05:37 AM

Rafael,

Keep in mind that there may be packages that are available to the community (Ernie's LORS) even though they are not part of the .LRN tarball. In fact, we expect lots and lots of creative activity and don't want to get in the way of this at all. In other words, someone could run .LRN 2.1 and still use Ernie's Lors.

What we want to set up is that something that is in the .LRN tarball has gone through a pretty rigorous process of getting operationally tested and used at least one of the constituent institutions. Lors is a brand new package, which means it first has to pass the test for becoming an OpenACS package. Then it can evolved into .LRN.

Overall, the question is also getting the collective feedback and putting the joint effort into areas that will benefit everyone. We all know there is only a limited amount of time and resources. Time and time again, I've heard that some of the low hanging fruit on the core modules and getting them solid is a major frustration, a block to adoption, and a big priority. Once these base issues are covered, the skys the limit in terms of new stuff to add. This is why I made the focus of the .LRN 2.2 release the core modules and bug fixes.

I love Ernie's LORS and want to completely leave open the freedom and space for that to evolve. Don't let the priorities of a particular release stop you.

4: Re: .LRN release process and roadmap (response to 3)

Posted by Matthias Melcher on 04/16/04 01:42 PM

Tracy,
if I understandstand your timetable right, this is what you recommend to institutions who do not want to branch and do not want to knit their own systems from CVS but rely on a tarball out of the box:

If they want to show their learners a webcontent called index.htm, intro1.htm, content1.htm, and summary1.htm, load it up to filestore, rename index.htm to 00index.htm to force it to be on top, and tell their students how to navigate to the filestore and click it? What else could be recommended with a dotLRN that is not branched, not self-knitted, and without Ernie's LORS?

7: Re: .LRN release process and roadmap (response to 4)

Posted by Tracy Adams on 04/17/04 02:43 AM

Matthias,

I didn't understand the specifics of your question. I can, however, give you a broad answer to what I was thinking.

People in the community develop and maintain code as packages. So the next step would be to work toward a package release of Lors. The process would then be:

-- Install the .LRN tarball
-- Go to the APM manager and install the other packages. This will grab the tarball of that specific package from the OpenACS site and install.

That way, institutions can have the flexibility of getting an official release of .LRN, not fork, and be able to try out some experimental packages. What you will be running on your site is a combination of the .LRN tarball and also a release of another package.

The .LRN "label" and tarball will be saved for packages that have made the criteria to be an OpenACS package, get deployed in at least one school, and go through the .LRN test/release process. The goal is to ensure the quality of what is labelled .LRN.

We have a whole bunch of new packages coming that will all be very valuable. To make things feasible, we just have to start with the highest and take one step at a time. The core of .LRN and the basic package hasn't gone through extensive testing (these last .LRN release have essentially been releases to pick up the OpenACS fixes). Case in point were the bugs people found the homework module last week.

Once the core parts of the product are stable, we then move to working on the newer packages. In the meantime, of course, there will be lots of activity on the other packages led by individual people and institutions. We never want to get in the way of this creativity and energy.

This is the same type of path the OpenACS community has been following. Recognizing that there is only so much time and energy, they focused on OpenACS core and not the packages. First, they fixed the most critical bugs. Then the next level of priority. Then the next. When the core is solid they can expand into some of the broader packages and functionality.