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

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

Collapse
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"?

Collapse
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

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

Collapse
13: Re: .LRN 2.0.2 release criteria (response to 12)
Posted by Joel Aufrecht on 03/08/04 09:39 AM
yes.
Collapse
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

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

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

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