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

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

Let's plan out what needs to be done first. You want openacs.org 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 openacs.org (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 openacs.org]$ pwd
/web/openacs.org
[andrewp@samoyed openacs.org]$ cvs stat -v readme.txt 
===================================================================
File: readme.txt       	Status: Up-to-date

   Working revision:	1.1.1.2	Thu Jul 25 19:21:25 2002
   Repository revision:	1.1.1.2	/cvsroot/openacs.org-dev/readme.txt,v
   Sticky Tag:		(none)
   Sticky Date:		(none)
   Sticky Options:	(none)

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

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

Basically, in this "openacs.org as branch of toolkit" scanario, openacs.org 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.

In this thread, Peter Markland argued, "If we can't support a site like OpenACS.org 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 OpenACS.org 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.

I have the feeling that the decision tends to the branch strategy: create a branch of openacs-4 in CVS, called openacs.org 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. staging.openacs.org 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 openacs.org-dev 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?

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.