Forum .LRN Q&A: Re: .LRN as a distribution of OpenACS

Collapse
Posted by Tracy Adams on
When I took the role of release manager of .LRN, the first obvious  question was "what it my role".  The role of release manager of .LRN  wasn't as obvious as release manager of OpenACS.  After watching a bit, I noticed there was confusion about what the .LRN release was and how it related to OpenACS.  I brought up the question last Thursday at the .LRN  weekly chat, specifically about the .LRN TAB.  This led to more discussion and Al's post, which will hopefully let us clarify things.

This posts outlines some of the documentation and processes that may  give the impression that .LRN is a separate development project as opposed to a distribution of OpenACS.  If we were to truly run as a distribution of OpenACS, we'd work to remove or reduce these things.

1) .LRN RoadMa(https://openacs.org/projects/dotlrn/roadmap) - Notice  that many of the packages are OpenACS. As a TECHNICAL and PROJECT MANAGEMENT page, this gives the impression that the .LRN has an independent roadmap of the basic platform.  What we are really seeing here is a proposed OpenACS roadmap. It has served us well, but it also presents confusion about what OpenACS and .LRN.  I propose
removing this page from the .LRN site and transferring it to OpenACS should they want to make use to it.

2) Separate Technical Committees - If .LRN is a distribution of OpenACS,  why is there a separate technical committee?  For example, when the .LRN initiative wanted to add internationalization, they worked with OpenACS and the OCT, not through the .LRN tab.  There is a desire for the .LRN members to be informed about technical developments and also to help ensure that OpenACS will meet the needs of universities.  However, it is clear that all the technical action takes place on as part of the OCT.  In practicality, this is how it has been working anyway. 3 of the members of the OpenACS OCT are on the .LRN Tab.  The proposal is to do away with the .LRN Tab because, again, it gives the confusing impression that .LRN is independently making technical decisions.

3) There are code differences between OpenACS and .LRN.  Although most of .LRN is core OpenACS or packages, there are differences, particularly in the portal and the master-template. It has gotten to the point that .LRN and
OpenACS can't coexist and that developers have to be careful when  developing OpenACS so they don't break .LRN.  These are historical and there is strong agreement that the differences should be removed.  Only question is getting the development effort.

4) Management of bugs.  After the release of OpenACS 5.0, we went through and labeled the bugs that were most important for .LRN and labeled them as "fix for .LRN 2.0.1" in the bug tracker.  The OpenACS community focused on  identifying bugs for OpenACS.  As a result, the .LRN bugs are kind of "lost" in the confusion between the 2 processes.  Some of these bugs are in the  OpenACS code and some are in the .LRN part of the code (the problem being the separation mentioned in #3.