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

Collapse
Posted by Tracy Adams on
Thanks Joel.  This ties back to the broader question that .LRN is a vertical application of OpenACS.  Utlimately, the .LRN release would be a given OpenACS release that is labelled .LRN because it is tested at Universities, plus perhaps a few specific .LRN-only packages.

First we have stuff that Heidelberg needs right away, like the translations.  I'll follow up with Carl and make sure we understand exactly what is left.  This is a special situation.

What about longer term? Looking at the bug tracker and those bugs labelled "fix for version .LRN 2.0.2", we have the following  categories.

1) Bugs that are in OpenACS or OpenACS packages that have been identified as necessary for .LRN installations.  These are 1392, 1383, 1339, 1210, 1107, 1050, 810, 736, 93, 63.  My suggestion is that we manage these type of bugs as part of the OpenACS process and label them for the next OpenACS release.  Joel, as OpenACS release manager, what are your thoughts?  I don't want to step on your toes.

2) There are bugs that are part of the portal system or portlets that are referred to as .LRN now.  Don is working on the OpenACS portal system and when this project is done, .LRN will use the OpenACS portal system and the portlets will belong to OpenACS.  Don also told me that the portlets in .LRN will need a little modification, but with that, they will be usable as OpenACS.  These are bugs, currently labelled "fix for version .LRN 2.0.2", that will be in OpenACS after Don completes this project.
1518,1387, 1261, 1248, 1217, 1216, 476.    My suggestion again is that we manage these type of bugs as part of the OpenACS process and label them for the next OpenACS release.

3) There are bugs that are very closely tied to .LRN, for example, things that configure or tie all the pieces together. Bugs like this that are currently labelled "fix for version .LRN 2.0.2" are 1511, 1314, 1225, 1214, 1068, 986, 961, 226.  I'd suggest that we manage these bugs however we manage packages.

Collapse
Posted by Joel Aufrecht on
My immediate concern is simply that Heidelberg is expecting to launch Real Soon Now, and my understanding is that they are waiting for .LRN 2.0.2 to do so.  If we take the current fix-for-2.0.2 bug priorities at face value, they have around twenty blocking bugs, spread out across all three of the categories you have identified.
So if I wait for all of these bugs to get closed before releasing 2.0.2, it's going to be months.  I thitk we, and by we I mean you, should check with Heidelberg/MIT and demote most or all of these bugs to pri 3.  Presumably they won't get fixed, and then we'll roll them to fix-for-2.1 pri 3.  But that's better than having a bunch of non-critical bugs mixed in equally with real showstoppers.
Collapse
Posted by Tracy Adams on
Joel,

You are right. The bugs currently labelled "fix-for-2.0.2" are spread out between
a) Heidelberg immediates
b) medium term bugs separate between the 3 areas I outlined

I'll do what you said - demote the medium term bugs to priority 3 once I talk to Heidelberg ASAP.  No problem.

I would like to talk about how to handle the other bugs by priority though.  I think it causes confusion to have OpenACS bugs labelled for OpenACS and .LRN.  Thoughts on the 3 categories?