Forum .LRN Q&A: Re: .LRN 2.0.2 release criteria

Collapse
Posted by Carl Robert Blesius on
We launched this past week in Heidelberg.

Here is a link to a text we prepared for our university press office (in German):

http://blesius.org/projects/openacs/dotlrn-launch-in-heidelberg

We launched based on 2.0.1 code and as soon as 2.0.2 comes out we plan to upgrade (2.0.2 should contain the newest translations from the translation server).

Staring with 2.0.1 we will be running a stock install in Heidelberg.

By doing this we are giving up some flexibility in order to help strengthen the platform for all (and reduce our risk long term).

So rather than holding releases back, we want to help push releases forward.

Collapse
Posted by Joel Aufrecht on
I'm still not sure where that leaves us for .LRN 2.0.2. If the only critical thing Heidelberg needs is new translations (and the two critical bugs that are already fixed), and those translations are done, then we oughtn't wait for any of those other bugs.

Re: the categories:

  1. Bugs that are in OpenACS or OpenACS packages that have been identified as necessary for .LRN installations. . Many of these bugs aren't Core OpenACS bugs. If they're not managed as part of the OpenACS release process, and they're not managed in the .LRN process, I don't see how they'll get fixed. By managed I mean someone compiles a list and asks people to work through the list and follows up and reassigns bugs that still aren't getting fixed and confirms resolved bugs.
  2. There are bugs that are part of the portal system or portlets that are referred to as .LRN now. These should either remain .LRN-only or move to Core, as appropriate.
  3. There are bugs that are very closely tied to .LRN, for example, things that configure or tie all the pieces together. These should stay .LRN bugs.
Basically, if bugs aren't assigned to a managed release, then the only way they're going to get fixed is if someone happens to work on a package on their own, and either runs into the bug themself or is courteous enough to check the bug tracker while they're working on the package. I think this does happen, but not often enough to call it a successful process.