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

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.