Forum .LRN Q&A: What is required for the next .LRN release?

I'm still trying to figure out exactly what is required for a new release, because before we have a complete release plan with schedule, we should know what we are trying to accomplish. Here are some options, recapping previous discussion:
  1. no new release. Use .LRN 2.1.1. Advantage: no work or cost.
  2. bugfix release. Take what is currently checked in on the openacs-5-1 branch, sanity-check and test it, and release it as 2.1.2. Advantage: definitely doable, offers new value. After discussion with Rocael, I will proceed with this while the bigger questions are in the air. Steps:
    1. Figure out exactly which packages are in .LRN 2.1.2. I will post a list based on the cvs module aliases so people can verify.
    2. Hack bug tracker so that we can see all outstanding bugs for this set of packages.
    3. Release 2.1.2beta1.
    4. Coordinate bug testing and upgrade testing.
    5. Check bug list, fix bugs
    6. Repeat previous step until there are no release-blocking bugs.
    7. Release
  3. Same as 2), plus address a few of the outstanding requests
         * Get some or all packages to maturity level 4
         * Incorporate the installers in the release process
         * Add full support for more languages.
         * Themes work ??
         * xhtml compliance.
         * feature requests from Heidelberg
         * other?
    
    Advantage: will make some users happier. Disadvantage: more work. Whether or not it's possible this summer depends on exactly which requests we commit to implement.
  4. Do everything on the list. Not possible in ~3 months without substantial funding; at the current rate of volunteer labor, probably not all finished by end of 2006.
I would like to get many of the passive participants more involved, certainly in upgrade testing and bug finding and fixing, and hopefully in tackling entire project. But to be conservative, we should assume that we don't get much out of that and we are at option 2 or option 3. Hence my question: what exactly is essential for the September release?
Collapse
Posted by Nima Mazloumi on
Joel,

I think we should take small steps but many. "no new release" is not an option. "bugfix release" is the way to go, so your "Hack bug tracker" idea is definetly great as it will reveal what has to be fixed by dotLRN. Considering application packages as true OpenACS packages not much is left for dotLRN except the dotlrn package itself and lors & Co and maybe ims-ent. In future maybe imsld.

We should really have the same what OpenACS has: a core. The dotLRN core should have no serious bugs.

All other application packages are integrated in dotLRN using dotlrn-* and the *-portlet packages. They are not too difficult to maintain since the first is almost the same in all packages and the second contains almost nothing except for the portlets.

So what it's really about are the application packages integrated in dotLRN. Here I would suggest the same policy as OpenACS does. They are not part of the core. There is only one difference: dotLRN is a product, so we need to guarantee a standard. Maybe we should certify that in correspondance to a maturity level a packages reaches. Below that level we don't recommend installation or upgrade and leave it to the decision of the administrator.

Regarding your third option I don't think that is is the job of the dotLRN consortium to take care of maturity levels. Even the installers are primarily the job of the community as are language support, xhtml compliance and themes. These goals depend more on the application developers or are part of the community process. Of course they are important for dotLRN but we cannot want what is not there. There really should be a separation of concerns or money. The first means dotLRN has to wait until the code is available the latter dotLRN has to raise money to make the code available.

Since there is also a commitment from dotLRN consortium or dotLRN institutions we should accept what is offered. From what I know there is some theme work going on in the community and also some have committed themselfs for the installers. If these effort bear fruits let's release them if they don't then don't. All we need is someone who set out deadlines for these activities and do some coordination.

I think we really should focus on dotLRN core bugs and work on the upgrade from OACS 5.1 to 5.2. Let those developing important packages like forums, faq, news, bulk-mail, assessment, evaluation, file-storage take care of maturity levels. This is a never ending process anyway. I have posted some thought on the maturity level here [1].

So here is my suggestion:

1. Release 2.1.2 with oacs-5-1 (bugfix release)
2. Release 2.2 with OpenACS 5.2 once 5.2.x is released (5.2 upgrade release) The ".x" is just an attempt to reduce the risk of broken important packages. Which the community has to take care of anyway.

- Since *-portlet and dotlrn-* packages don't really change new versions of the corresponding application packages will be available via the online upgrade anyway. So all we need to do here is to increase the version numbers so that they reflect a new version of the application once that exists.

- Work on a stable Lors & Co. release with an upgrade to lors central. This application is essential for any learning management system.

[1] https://openacs.org/forums/message-view?message_id=301726

Collapse
Posted by Alfred Essa on
What's maturity level 4? The OpenACS TIP goes up to 3...
Collapse
Posted by Joel Aufrecht on
Maturity level 4 is a proposed ".LRN-certified" level.