Forum .LRN Q&A: .LRN 2.1

1: .LRN 2.1

Posted by Tracy Adams on 05/04/04 10:43 PM

First, a reminder about the .LRN plan in this post.

Now that OpenACS 5.1 is out, I'll be cutting .LRN 2.1. The purpose of this release is to:

Provide a tarball that includes the multitude of fixes in OpenACS 5.1
Fix critical fixes blocking launching and upgrades.

I need to know if there are any issues in category #2. Please make a ticket and email me at teadams@mit.edu.

Shortly, I'll be posting the project plan for .LRN 2.2. Heads up that the beginning of this will include

Gathering information about the core modules and creating a big list of all the "todo"s for the core .LRN modules. Start thinking and planning to get your feedback in for the next 2 weeks.
Recruiting a team of people that are willing to be intimately involved with the process (testing, fixing bugs, etc). Please let me know if you'd like to be on that team.

Tracy

2: Re: .LRN 2.1 (response to 1)

Posted by Tracy Adams on 05/05/04 05:53 PM

I've just been at the OCT meeting working out how the .LRN and OpenAS coordination will work.

It came up, who would upgrade to .LRN 2.1 as it is defined above? The thing is, it will just be a quick release (basically a labelling) that will capture the OpenACS 5.1 changes. However, there is another way. If someone wanted one of those changes, they could upgrade the OpenACS packages via the APM.

There is one other trick in that picture. The file storage package in OpenACS 5.1 has a big upgrade and the other packages don't work with that yet. So as a whole complete picture, it doesn't make sense yet for .LRN.

The idea came up in the meeting that maybe .LRN 2.1 should be the stability release that we are working on for the summer.

So give me feedback, if I don't put together a tarball that includes the OpenACS 5.1 changes, will that effect anyone? If I don't hear back, I'm not going to cut this release and put all my focus on the project plan for a well-tested version.

Can we all get on board on working on a really stable, well tested .LRN release for this summer?

3: Re: .LRN 2.1 (response to 1)

Posted by Nima Mazloumi on 05/05/04 06:18 PM

Hi Tracy...

when do you expect the release of the well-tested version in summer? And will it include OpenACS 5.1? I think we shouldn't stay far behind the OpenACS releases. Don't you think?

The only concern I have is that this will result in a big release with long delays since we want to have
- OpenACS 5.1
- all the improvements other universities have locally
- bug fixes to homework and other dotLRN packages
- improvements of forum package
right?

Greetings,
Nima

P.S. I am more than happy to help out for the next release and Dave offered help with the file-storage and webDAV(https://openacs.org/forums/message-view?message_id=179617).

4: Re: .LRN 2.1 (response to 3)

Posted by Tracy Adams on 05/05/04 06:37 PM

<blockquote>>when do you expect the release of the well-tested version in summer?
</blockquote>

We'd plan to have Sloan launch on a release candidate in July and release the final version is August.

<blockquote>> And will it include OpenACS 5.1? I think we shouldn't stay far behind the OpenACS releases. Don't you think?
</blockquote>

It will include at least OpenACS 5.1. I'm still in the process of working with the OCT on what is happening with OpenACS.

I think we need to balance to things:
-- Staying as close to OpenACS
-- Making sure our releases are high quality and well tested

<blockquote>>The only concern I have is that this will result in a big release with long delays since we want to have
>- OpenACS 5.1
</blockquote>
Yep

<blockquote>>- all the improvements other universities have locally
</blockquote>

This is a goal. It depends on universities stepping up and helping.

<blockquote>>- bug fixes to homework and other dotLRN packages
</blockquote>

Yep, this is the goal. Again depends on people contributing the resources.

<blockquote>>- improvements of forum package
</blockquote>

This depends on funding/resources. If those are there, the improvements would be in the release.

I need to know who is stepping up to the plate to help make this happen.

Tracy

5: Re: .LRN 2.1 (response to 1)

Posted by Samer Abukhait on 05/05/04 07:45 PM

I am ready to help, but need a guide on what to do

6: Re: .LRN 2.1 (response to 1)

Posted by Nima Mazloumi on 05/10/04 12:57 PM

Tracy, there are some serious calendar bugs that Dirk fixed for 5.1 and I was wondering how difficult it would be to release 2.1 simply to support 5.1?

7: Re: .LRN 2.1 (response to 2)

Posted by Malte Sussdorff on 05/10/04 01:08 PM

Out of curiousity. Do you have to include FS 5.1 compat or would it be sufficient to declare all 5.1 packages dotlrn-2-1-compat except File Storage and use the old File Storage with the dotlrn-2-1-compat tag?

I do think a release with as many improvements from the various packages that work, based on OpenACS CORE 5.1 would be a nice thing.

8: Re: .LRN 2.1 (response to 6)

Posted by Matthias Melcher on 05/10/04 04:35 PM

Nima wrote
<blockquote> there are some serious calendar bugs that Dirk fixed for
5.1 and I was wondering how difficult it would be to
release 2.1 simply to support 5.1?
</blockquote>

Similarly, there is a crucial forums problem that is also fixed in 5.1 and I think it's important to see it in the new dotLRN: https://openacs.org/bugtracker/openacs/com/dotlrn/bug?bug%5fnumber=1652

9: Re: .LRN 2.1 (response to 8)

Posted by Tracy Adams on 05/11/04 12:15 AM

Hi everyone,

No need to wait for a release for these changes, you can have them now. You can just upgrade to that OpenACS package from the APM. Just grab those distributions.

What you won't get and we still don't have is a well-tested, well-oiled, .LRN release. That is really going to require us to take a step back, work as a team, and go through a real release process. (See my next post)

10: Re: .LRN 2.1 (response to 9)

Posted by Joel Aufrecht on 05/11/04 01:01 AM

In order for automatic upgrade to work, two things must be true:
1) The version number of the bug-fixed package must be incremented. We can use the dot release number for this. Suppose package foo is on version 3.0 and it gets a bug fix. It should now be 3.0.1.
2) The version must be tagged as compatible with the kernel. Since .LRN 2.0 runs on OpenACS kernel 5.0, this means that the version must be tagged with openac-5-0-compat. This gets a bit confusing when the bug fix is on the version of the package that's on the 5.1 branch. It's still just a matter of tagging, but you have to be sure that the 5.1 code is still compatible with 5.0, and that the upgrade works.

If the developer does all that, then in order to get the fix, admins only need to go to the APM and click Upgrade From Repository and pick that package. If you are running from a local cvs repository, it's a bit more complicated but it's all documented, as noted above.

11: Re: .LRN 2.1 (response to 1)

Posted by Nima Mazloumi on 05/11/04 01:51 PM

If I use the APM will I still be able to upgrade to the next dotLRN 2.1 release?

12: Re: .LRN 2.1 (response to 1)

Posted by Bruce Spear on 05/27/04 03:39 AM

Tracy: might you answer Nima's question? I've still got that nasty bug: https://openacs.org/bugtracker/openacs/bug?filter%2eactionby=125840&bug%5fnumber=1797 that you suggest has been fixed with 2.1, and I'd like to be able to add some users without having to rebuild a table by hand. Thanks! Bruce

13: Re: .LRN 2.1 (response to 12)

Posted by Tracy Adams on 05/27/04 05:25 AM

The answer to Nima's question is yes.

Bruce, we can't reproduce bug 1797. It may be we are not checking correctly. Can you please verify it is fixed on the test server (http://test.openacs.org and close the bug if so!

Thanks, Tracy