I'm actually more in favour of running OpenACS.org on a stock cvs checkout of the latest release branch and keep the changes in a seperate place. I don't see one reason why OpenACS.org should differ from the toolkit with regards to functionality. If the community wants to use it in a certain way, we better get that code as fast as possible back into the toolkit (and what better way then to use the stock cvs as our repository).
I'm not sure about the nature of the changes that caused so much trouble, but after a CVS update to the latest release, we should be able to re-checkout the changes repository on top of our current installation and be happy with it.
Last but not least, upgrading OpenACS should become considerably less burdensome and be executed on a regular basis. Not wanting to put too much work load on the release manager, but I'd be really happy to see him charge after some people let's say two weeks after the release to upgrade openacs.org to the latest one (and make an upgrade of openacs.org a showstopper for the next release).
