Forum OpenACS Development: Migrating OpenACS.org to a branch in the OpenACS repository
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: 220.127.116.11 Thu Jul 25 19:21:25 2002 Repository revision: 18.104.22.168 /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: 22.214.171.124) openacs-4-6-beta-2002-08-05 (revision: 126.96.36.199) openacs-4-6-devel-2002-07-31 (revision: 188.8.131.52) openacs-4-6-devel-2002-07-25 (revision: 184.108.40.206) openacs-4-5-devel (revision: 220.127.116.11) 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.
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. openacs.org can be run directly from the stable branch. Bugfixes in the stable branch (and thus in openacs.org) 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.
openacs.org 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.
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 openacs.org will have customized code. So we want to merge bug fixes in both directions. Right now we made some changes to the openacs.org 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 openacs.org is running the latest code as well as make it easy to merge in bug fixes, or merge fixes from openacs.org back to openacs.
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?