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

Posted by Joel Aufrecht on 03/04/04 01:04 PM

I'm posting because I'm a bit fuzzy myself on where we're at and what still has to be done. I would ultimately like this question to be answerable via the bug tracker - ie, any bug, task, or work item that prevents a release is in the bug tracker, with the appropriate "Fix For", and priority 1 or 2. (I have changed the priority 2 label to "Must Fix Before Next Release" to reflect that all priority 2 bugs are release-blockers.) So perhaps the answers to the following questions can be made in the bug tracker.

What are the release criteria for .LRN 2.0.2? There are currently 25 open bugs, 3 resolved bugs, and 5 closed bugs. Since .LRN's needs are tied to the pending launches of Heidelberg, MIT, et al, I am asking the .LRN TAB/PM (Tracy Adams) for instructions on when to release 2.0.2.

.LRN 2.0.2 also has two dependencies:

OpenACS core. I don't believe that there is anything in OpenACS core that .LRN 2.0.2 needs, with the possible exception of translations. Just to be safe, we could do a 5.0.4 to catch are any new core translations. If so, what is the best timing for this?

OpenACS dotlrn-prereq. This is all of the OpenACS non-core packages that .LRN requires. There were several critical bugs here (file storage and calendar), which Dirk Gomez has taken the lead in fixing. There are also new translations, which may or may not be essential for .LRN and may or may not be complete.

2: Re: .LRN 2.0.2 release criteria (response to 1)

Posted by Tracy Adams on 03/04/04 08:23 PM

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.

3: Re: .LRN 2.0.2 release criteria (response to 2)

Posted by Joel Aufrecht on 03/04/04 10:14 PM

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.

4: Re: .LRN 2.0.2 release criteria (response to 3)

Posted by Tracy Adams on 03/04/04 10:22 PM

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?

5: Re: .LRN 2.0.2 release criteria (response to 1)

Posted by Carl Robert Blesius on 03/07/04 02:12 AM

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.

6: Re: .LRN 2.0.2 release criteria (response to 5)

Posted by Joel Aufrecht on 03/07/04 12:04 PM

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:

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

7: Re: .LRN 2.0.2 release criteria (response to 1)

Posted by Tracy Adams on 03/07/04 04:54 PM

Hi Joel,

I talked to Carl last night. Yes, he is ready to cut a release at any time. There are no bugs needed.

Regarding category 1, when you say that "Many of these bugs aren't Core OpenACS bugs.", I'm curious what you mean. I put bugs that were either in OpenACS core or OpenACS packages on the category 1 list, so I want to understand your statement.

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

You hit the nail on the head :)

8: Re: .LRN 2.0.2 release criteria (response to 7)

Posted by Joel Aufrecht on 03/07/04 08:17 PM

Look at the difference between https://openacs.org/bugtracker/openacs/core?filter.fix_for_version=163478&filter.orderby=priority
(fix for .LRN 2.0.2, core only)
and https://openacs.org/bugtracker/openacs/?filter.fix_for_version=163478&filter.orderby=priority
(fix for .LRN 2.0.2, all open bugs)

These bugs from your category 1 list: 1210, 1050, 810, 93, 63
aren't on the core list. Anything that's a .LRN prereq but not in OpenACS Core (the packages you get from the cvs alias acs-core). They're category 1, but they're not technically core bugs, so they should be .LRN bugs, not OpenACS bugs, if they are .LRN showstoppers. Reason being, we want Core to be as small as possible so it can be released as easily as possible.

9: Re: .LRN 2.0.2 release criteria (response to 8)

Posted by Tracy Adams on 03/07/04 08:35 PM

1) Now that I got in touch with Carl, we don't have any .LRN showstoppers. There is a list for the medium term, but nothing I know of that should hold up the next OpenACS release. So there is no short term issue.

2) I'm working to understand your label of "OpenACS Core". So bug 810 is "Upload of files failed" and therefore in the file-storage package. I'm a bit confused whey that isn't OpenACS. Maybe your are making a distinction between OpenACS core and OpenACS packages?

3) Now that we've clarified that .LRN is a vertical application of OpenACS, by goal is to really work through the OpenACS community as opposed to looking like we have a separate development and release package just to cause confusion. .LRN succeeds as a technical platform by first making OpenACS great. I have time available, so perhaps the question should be "what can I be doing to help with the OpenACS release process"?

10: Re: .LRN 2.0.2 release criteria (response to 9)

Posted by Tracy Adams on 03/07/04 08:47 PM

I'm looking at your filter and I understand a little more I think. You went through and labeled what you consider ACSCore (7 bugs) Some of those where my category 1 list. Others were from by category 2 list (I put some of the group stuff there). Some that were on my category 1 list and you didn't agree they were ACSCore.

I guess I'd follow that as a first step, can we move these and get those 7 in the OpenACS release. That will be a start at getting clarity. Thank you, Tracy

11: Re: .LRN 2.0.2 release criteria (response to 9)

Posted by Tracy Adams on 03/07/04 08:49 PM

I've relabeled "Fix for version 2.0.2" to "fix for version 2.0.3" so the ticket tracker is clear we are not waiting on anything for version .LRN 2.0.2.

12: Re: .LRN 2.0.2 release criteria (response to 9)

Posted by Malte Sussdorff on 03/08/04 09:20 AM

My understanding of the whole Core business is like this:

We have an OpenACS Core. This consists of all packages needed to get a site up and running so you can then go to the administration interface and add new packages from the repository. The Core is the smallest tarball release possible.

We have .LRN as a vertical application. As this is pre-packaged, this has additional needs. File-Storage is one of them, forums, portals and others. Basicly everything that is marked as "to be installed in bootstrap mode" in the /packages/dotlrn/install.xml document.

The categories in the bugtracker should reflect this. Bugs that apply to the highest level (OpenACS core), should be labeled as "fix for release <of OpenACS>". Bugs in packages that are used by .LRN (*in the default install*) should be labeled as "fix for release of .LRN". All other bugs will never be showstoppers and should never be assigned a "fix for release" of OpenACS or .LRN. They get fixed when someone works on them and it should be in the best interest of all, if you fix all outstanding bugs in a package before adding it to a new site.

Joel, Tracy, does this match your ideas ?

13: Re: .LRN 2.0.2 release criteria (response to 12)

Posted by Joel Aufrecht on 03/08/04 09:39 AM

yes.

14: Re: .LRN 2.0.2 release criteria (response to 12)

Posted by Tracy Adams on 03/08/04 04:28 PM

I understand what you are referring to "OpenACS core" now by Malte's post. So that takes care of category 1.

For packages like file-storage and forums, I'd claim these are OpenACS packages. Yes, .LRN makes use of it but so do other OpenACS installations. I believe these packagse should be managed by whatever release process we use to manage OpenACS packages. The people involved with .LRN should be highly involved in the OpenACS community improving all these packages, but through the OpenACS process.

My next question would be. Given that OpenACS core as Malte has defined it, how are OpenACS packages managed?

Thank you,
Tracy

15: Re: .LRN 2.0.2 release criteria (response to 14)

Posted by Malte Sussdorff on 03/08/04 07:52 PM

You are not going to like it Tracy, but the answer is a clear and sound "Not at all". Noone is managing the packages, we do not have package maintainers and we do not have release criteria for packages.

Therefore my excursion that packages which are used in a vertical application should be managed by said vertical application release manager (for .LRN this would be you, I guess), as you have to make sure before the release, that the packages you bundle together to make up the vertical application are actually working.

This beeing said, I don't want to imply the release manager has to fix all outstanding bugs. This is what bug bashes are for and this is how Joel has handled the OpenACS *core* releases so far, along with the commitment of the OCT to help and fix bugs.

With more and more universities coming on board I hope that some of them will provide the manpower to help out with quality and bug fixing, thereby making .LRN releases easier and faster.

16: Re: .LRN 2.0.2 release criteria (response to 15)

Posted by Tracy Adams on 03/08/04 08:18 PM

>>You are not going to like it Tracy, but the answer is a clear and sound "Not at all". Noone is managing the packages, we do not have package maintainers and we do not have release criteria for packages.

Ok, I see. So we've identified the real issue!

I think the first step would be to work with OpenACS and help with that area. Al and I have talked about this and I'm "oked" to spend my Sloan time helping with the management with OpenACS packages.

I've been pushing for clarity because I want to do things in a way that makes sense and works for the long term. I want OpenACS to be strong and the OpenACS packages to be strong for everybody, not just .LRN. I think that chances are the same people will be doing the work, but do not want the process to look like .LRN takes over the base development.

Remember, the reason we concluded that .LRN was a vertical application was that we wanted to recognize that it was primarily a marketing effort and not a replacement for the technical community of OpenACS.

So, if the OpenACS would have me, I propose that, as a member of the OpenACS community, I move over to the OpenACS bboards and work on the package management process and getting maintainers....

17: Re: .LRN 2.0.2 release criteria (response to 16)

Posted by Malte Sussdorff on 03/09/04 07:35 AM

So, if the OpenACS would have me, I propose that, as a member of the OpenACS community, I move over to the OpenACS bboards and work on the package management process and getting maintainers....

I don't think anyone will object to this Tracy. Getting someone to manage the release of packages is really great and much appreciated I'd assume. But let's discuss the management and release cycles over at the OpenACS forum. Looking forward to your announcement there.

Thanks to both you and Al for providing the time to manage OpenACS packages.