Forum OpenACS Development: Migrating to a branch in the OpenACS repository

We really need to get onto a branch of the openacs CVS repository. I am willing to do work merging the existing mix of 4.5/4.6 code with 4.6.3 if someone can help setting up the CVS branch and bring in the existing code.

Any volunteers?

Yes maybe. (Let's chat this weekend or something...)

Let's plan out what needs to be done first. You want to be a branch in the normal OpenACS cvs repository and project, have I got that right?

The normal way to run a website like OpenACS would be to create your own cvs project for (which in fact has already been done), and import each release of OpenACS onto a vendor branch in that project. I believe that was also already done for OpenACS, starting with an early 4.5 development snapshot, e.g.:

[andrewp@samoyed]$ pwd
[andrewp@samoyed]$ cvs stat -v readme.txt 
File: readme.txt       	Status: Up-to-date

   Working revision:	Thu Jul 25 19:21:25 2002
   Repository revision:	/cvsroot/,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

   Existing Tags:
	openacs-4-6-beta-2002-10-08	(revision:
	openacs-4-6-beta-2002-08-05	(revision:
	openacs-4-6-devel-2002-07-31	(revision:
	openacs-4-6-devel-2002-07-25	(revision:
	openacs-4-5-devel        	(revision:
	OpenACS                  	(branch: 1.1.1)

The advantage of instead making a branch of the normal OpenACS development tree is that doing so should integrate much more tightly to the stock OpenACS releases, and should make it much easier to merge fixes back into the stock toolkit, and also to aggresively move newly developed toolkit code onto even before a new version of the toolkit is tagged release if (and it's a fairly big if, I think) the maintainers decide they want to do that.

Basically, in this " as branch of toolkit" scanario, becomes another branch of the toolkit to be maintained just like the current 4.6 stable branch, rather than the more typical, more loosely coupled, "cvs import into another project" way of doing things.

I've never done that before, as for most projects (due to the design of CVS) you simply don't even have the option. It sounds like a reasonably good idea, but let's make sure it's the right thing to do. I'd like to see a bit more discussion and planning first, or links to such if that's already happened. Particularly the opinions of other folks like Jeff Davis who have done the most extensive work merging and updating the different OpenACS toolkit branches so far.

I don't think you need to create another branch for You could just run directly from OpenACS-STABLE. This is what I mean:

1. HEAD always has the latest development sources. It's considered unstable and fit only for innovations and major work. This would be OpenACS-CURRENT.

2. As we approach a release, HEAD stabilizes (feature freeze) until the release engineers think it's stable enough to make a release. When the release is made, HEAD is branched as a .0 release (OpenACS-4) and a symbolic tag is made for the actual release (OpenACS-4.0). The new branch will be the stable branch.

3. can be run directly from the stable branch. Bugfixes in the stable branch (and thus in are integrated with HEAD.

People who want to stay "Current" with OpenACS will just follow HEAD.

People who need stability will just follow the latest STABLE branch. could periodically sync with the STABLE branch.

This is more or less how the FreeBSD project manages their OS. I think it's a good methodology.



In this thread, Peter Markland argued, "If we can't support a site like out of the box with OpenACS then [something is wrong]," and I very much agree with this. The difference between a great toolkit and a good toolkit is in how it's maintained. If you need a new feature and you find something close in the toolkit and you modify it, the toolkit is static. If you can add your feature in an optional, backwards-compatible way and put it back in the toolkit, the toolkit grows. We need to keep lowering the bar for newcomers to work in that second way - in part by setting an example. I think we should try to run off of stock, keep it at the current version, and make upgrading it successfully and without errors a gate condition for beta and rc releases.

Actually, I am pretty sure Jeff actually suggested this a while back.

I think we want to use a branch, and not just run off of a tag, because will have customized code. So we want to merge bug fixes in both directions. Right now we made some changes to the code but were not easily able to merge those changes back to openacs.

So running off a branch of openacs should make it easier to make sure is running the latest code as well as make it easy to merge in bug fixes, or merge fixes from back to openacs.

I have the feeling that the decision tends to the branch strategy: create a branch of openacs-4 in CVS, called for example, and initially make it a copy of oacs-4-6 HEAD, trying to stay as similar as possible to oacs-4-6. This would make it very easy to merge bug fixes in both directions and have a decent live demonstration of the toolkit.

Now how to get there from the current suggestion as quickly as possible? I would suggest to simply create the branch in CVS, check it out to a testing instance, e.g. and fill the db of that instance with a copy of the production db. Then go through each area of the site manually and copy over necessary changes from the current code. The site isn't that big, and this way we are really only copying the stuff over we want and no old bugs.

Jeff - if you agree could you create the branch in CVS please?

Hm, that basically sounds like a good plan to me Tilmann. Only change I'd make is do not branch off from the tip of the 4.6 branch, branch it from the tagged 4.6.3 release.
I'm with Andy. I think we should work off of the current release. Then it will be easier to upgrade to each new release.