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

Collapse
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?

Collapse
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.