Forum OpenACS Q&A: Planning a migration from ACS 3.4.x to OpenACS?
anywhere, and that any such effort would be extremely painful and
time-consuming. I'll still rather pissed that aD never offered a
I'm curious what all the ACS 3 sites are doing development-wise. There
hasn't been a code repository for ACS 3 for over a year, and when I
inquired around about it, nobody seemed particularly interested in it.
It does seem like there were a lot of sites built on ACS 3.4, though,
and I imagine at least some of them must be under development.
So, my questions are:
1) If your site is built on ACS 3, do you ever have a plan to migrate
it to OpenACS?
2) If there are enough people thinking about this, wouldn't it make
sense to band together and create a migration guide / set of porting
tools to migrate as much of this data as possible to the new data
models? Perhaps we could share the pain and get it done more quickly.
3) If you plan to stick with your current platform of ACS 3, would you
be interested in helping out with maintaining a repository? Ybos has
volunteered to host it, but I don't think they have enough time to
maintain it. I'd be happy to help out, but I'm not sure how many other
folks out there are in the same situation as me. I'm already
maintaining a code repository for my own use. ;)
4) If I did go through all the pain of porting everything to OpenACS,
would I be rewarded with a platform that's going to have a migration
future? I'm not interested in another dead end... Is OpenACS 4 going
to be able to be ported to OpenACS 5?
5) I have a lot to contribute to OpenACS if there was a way to get
there from here. I've refined the Intranet portion of the ACS 3.4 code
full-time for over a year now, and developed the interface quite a
bit. I would love to bring these changes into the public domain so
other people could use it.
Yes.2) wouldn't it make sense to band together and create a migration guide / set of porting tools
This sounds like a good idea. In particular, simple instructions about how to migrate/create group memberships and user bases to OACS4 would be most appreciated
Jade, please don't let the lack of repository stop you from sharing your work. I would love to try your new intranet module.
Until the new website and a repository comes out, would you consider creating a classic acs 3 repository in at http://openacs.org/new-file-storage?
But that doesn't mean I have no *community* interest in spending a *small* amount of time on it. Particularly since the community seems somewhat nervous about the possibility that the existing code at aD might become inaccessible in the future (i.e. the "preparing for aD's death" thread). I was less motivated a few months ago when the issue was raised because, after all, if it were important to aD's user community one could argue that aD should step up to the plate and open up a CVS tree. But it is clear now that this will never happen.
Does someone want to step up and offer to put together a tarball of the real, non-ACES 3.4? (Malte is hosting their improved ACES, which is based on 3.4). Who should have commit access to a 3.4 tree if we build one? I think we need someone in the community to step forward and take on the roll of caretaker and gatekeeper for the repository. There needs to be some process for deciding whether or not, for instance, to put Jade's intranet changes into the tree or not.
This is where I duck out. It's work enough having that role for OpenACS 4.x and Roberto probably feels the same as he has that role for OpenACS 3.2.x. So someone from the ACS 3.4 user community needs to step forward if we're going to make this work.
Migration tools would be great. A 3.4. repository should be "temporary" in that "eventually" folks should migrate their improvements/packages to the 4.x framework. (I use quotes because I realize that to some degree this is a fantasy, life's too short, but we should have this as a goal).
What this would mean, however, is that I would be biased towards all the changes I've made in the last year to the ACS :)
Its just like everything else in the ACS..if you don't need the education set-up then just don't use those pages.
BTW I've been working a bit with the 3.4 intranet pages and would be interested in anyone else's work. I'd also be especially interested if anyone has done something interesting with address book and hooking it up better to intranet or using it for spamming.
If anyone is interested Scott and I put together a "Link Library" based on general-links "Goal Tracker" based on ticket tracker.
Hopefully Malte's fixed those problems?
Also I don't think it's exactly true that you can just choose not to load the education stuff and then have a vanilla ACS 3.4. It's been a couple of months since I worked on the code base for Sloan, but IIRC there were some hacks to things like registration that changes stuff.
A cleaned-up ACES code base would be fine with me (and, again, maybe Malte et al have done the necessary work) but the tarball as it exists at aD has problems.
- We run on ACES. One strong reason we picked it was my conviction that MIT wants to migraate their current data into .LRN which will be OpenACS based. Which leads to
- yes, and we should work together with OpenForce, if they want to.
- We will keep an ACES 3.x version running and integration all the code we get from people. The current problem is time on our side. The way I see it, we have an improved ACES version from Sloan. Add to this bugfixes made on our ACES installation. Plug in Jade's intranet and Carolines other improvements. Should make a decent package. There are problems though, which I'll come too.
- In my opinion OpenACS is the way to go in the long run. At the current moment the only reason for sticking with 3.4.x is that it is running in so many different places realiably, why change. Just make sure you can migrate your data. And if I'm not mistaken, not only Sloan is migrating data to OpenACS but some other company starting with an A is working on it too.
- Hand over your intranet module. I'm more than happy to integrate it with the ACES package to ship it around.
- Our ACES version is geared towards performance. Permission model sucks big donkey balls, Subgroups work more or less. We run at 40.000 users with 6000 groups and an average participation of 10 groups per person. So we were forced to get rid of everything which looked remotly like "sophisticated" permissioning and group system. Bringing this back into the main trunck is a little bit more work down the road.
- ACES Sloan does not install out of the box.
- Who is to decide, what package version will stay in the distribution. IMHO I'd use improved ACES/Sloan as a basis, drop the old bboard (though we still use it), take the munich file storage (we have it), add general alerts and survey, take the new intranet and integrate Carolines source codes. But why should this be the wisest thing to do .
- Who is going to test this, where is it going to run live with users. My idea is to setup ACES for german universities to test it out. Like an ASP approach. But see my problem. ACES does not support multilinguality (well, with out patch yes, but who is going to wrap TRN tags around every english paragraph in the ACES). A fork (again) for a german version (oh, I forgot, I have a germanised version made by my students, this is I guess the 5th version of ACS 3.4.x we talk about)
Still, I would love to see this stay an open process. So what I will do is upload the latest CVS checkout from the AIESEC.NET source as well as the ACES / Sloan package to www.sussdorff.org. Download it from there and play around with it. I can even start to host the CVS repository if you want. This would first consist of the ACES / Sloan package and further additions could be checked in by the various parties interested.
However, I wonder if our goals are mutually exclusive. My company needs very strict permissions on everything and performance is a secondary concern. Your situation is the opposite. I'm not sure if it's going to be possible for the Intranet package to work on ACES.
However, I am interested in a migration path, and if there was any way we could resolve these differences, I'd be interested in it.
Jerry, I can tarball everything up and upload it, but I'd rather wait until I see what happens with this thread. If we can have a real system in place for tracking bugfixes and a repository, I can save myself a lot of duplicate effort.
Malte, same thing for integrating it with ACES. I'm happy to, but let's see how this plays out first.
our client wants to move to a more sophisticated permissioning sooner or later and if we start with the ASP approach for universities it is definitly a must, so our interest are not opposite, though my focus is at the current stage probably more on performance .
Furthermore, I could setup SDM on the demo system we will come up with (and there needs to be a demo system, taking the request I already got in germany). And the CVS repository. Just bear with me after 1st of November as I'm pretty busy til then at least.
Always take in account that ACES is all about permissions, so integrating the Intranet Module with the ACES is a good idea. Though a different focus. Because the intranet module is just another portal to the functionalities of the ACS. Integration would be really nice if we could have the intranet homepage run as a portal. That would rock, so to speak. But thats even more dev-work.....
Okay, gotta head of for a few hours of sleeping beauty
So while hosting it on the openacs.org server is certainly possible, letting Malte do the hosting might make more sense. We could alway link to his server - "looking for the Good Old Days? You can find them over here!".
The permissions model's is going to be an issue in OpenACS 4, too ... not that I want this thread to diverge but I keep worrying about its scalability ...
I really wish I'd had your code a month ago when I started to hack in pieces of the intranet module into teamhydroski. I may be back on that project shortly...or never...but I'd love to know what sort of functionality your module has.
Is it a package? Can it be released as an "at your own risk alpah" package so if someone else is trying to create an intranet they have a starting point?
How hard would it be to integrate it into pre-ACES 3.4?
When I started using the customers code from intranet on my ACES installation I simply created a link to intranet/customers...fixed a few bugs so the pages ran...renamed some of the fields...and we were off. For my little bitty company it was not necessary to actually create a portlet or anything fancy. I fix the UI a bit every week.
I wonder if I would have had a better UI faster if I had had your code..even if I would have had to go fix a few things to make it compatable with my 3.4 version.
This is what I've found frustrating about not having a common code-base the last year. We could have been collaborating on this and benefited both of our companies (and made ourselves look better as employees as well).
Here are some of the changes I made to the Intranet:
- A lot of interface fixes and improvements (this is mostly what the improvements are). I had to make it usable for a company of very computer illiterate folks, so I cleaned it up quite a bit.
- Some bug fixes of course, and a few performance tweaks.
- We wanted a way of keeping track of to-do items, so I adapted to ticket system to do this. Its interface is a little better, although one of the best changes is a hack that I know won't be portable. (it was early on when I was still learning the ropes)
- We made projects so they can be hierarchical. I also added a lot of hour reports, so you can break down hours in all sorts of ways.
- I added "ticket templates", so if you typically do something and need three other people to do something related to it, you can do it all at once, and then you have a master ticket which shows you the status for all the subtickets (the subtickets are what you assigned to everyone).
- I added in the conference room package (that was developed at aD) and cleaned it up a little more.
- The rest of the changes are separate packages that are proprietary for the company I work at. I don't know anything about ACES, so I don't really know how hard it would be to set up. I haven't used SourceForge much, so I don't know whether to throw stones or not. Is it that bad? I would prefer the SDM and so on, but I'm openminded.
Perhaps we could share the pain and get it done more quickly.Many months ago a few of us upgraded a production client from an acs3.2 base to acs4.0. At the time I asked Mike Bonnet to write up a summary of the work (which he did most of). For what it's worth, you can read about it at http://grumet.net/random/mikes-migration-guide/. I haven't looked over much OpenACS code lately, but I suspect the bits about migrating users and groups will be relevant. There was also some weird incompatibility with ns_adp_parse/ns_adp_include and the templating system that we never figured out (perhaps you have?). Anyway, hope this helps.
What I'd ultimately like to see is a step by step guide, similar to the original install guide, which shows exactly which steps to take in order to make the switch to OpenACS 4 or Classic ACS 4. Perhaps we can use an iterative approach -- the next person to do a conversion can use your guide, and improve upon it, and the next person can improve upon that, etc...
It would be nice to have a forum for discussing these issue, but perhaps we can use this thread for now?
1) set up a code repository (nobody responded to my query about sourceforge... is that a viable option?)
Crucial issues (for me): are ACES and ACS compatible enough that my Intranet code isn't going to need a lot of work to get running on ACES? Is the functionality required by the Intranet going to break what you need, Malte?
Once we've resolved the issues, who is going to set this up? Malte, were you interested in doing this?
2) set up a forum for discussing ACS 3.4.x development.
Aside: Can we agree to call the new version ACS 3.5?
Who is going to set this up?
3) What else?
As for who is going to set it up, etc, I'd still prefer to do it here, I think. We want this place to be "ACS Tcl central" if possible, don't we? The more I think about it the more I think that's right.
I can spend some time setting up the basics on the openacs.org server (i.e. set up /cvsroot/ACES or /cvsroot/ACS) once someone decides they'll do everything else that's necessary.
I'll have to do some work filtering through all my bug fixes and changes and check in all the changes that aren't proprietary. I'm more than willing to do this. I think you'll all be happy with the improvements to the Intranet portion in particular.
Don, I don't really care whether we go with ACES or ACS, so unless anybody else has any objections, let's go with ACES. Can we call it ACS 3.5, though? I think it's far less confusing.
I'm willing to be the person who manages the forum for ACS 3.5. I can help with the repository, too, although I'm not sure if I should be the person solely responsible for it.
I do think it should unpack to a nice usefull portal rather then "your workspace", though proably not an education specific one. The portal layout with portlets for many of the modules gives people a much more accurate first impression of what ACS can do.
ACES to ACS 3.5? Doesn't the copyright holder for ACS have to
agree to this kind of name change?
On a side note, making a very specific configuration of ACS be
the name holder rubs me the wrong way. ACS 3.4 can do a lot
that is not readily apparent in the ACES version. I think you
actually create confusion by doing this sort of renaming. The
lineage becomes fuzzy.
I guess people can always grab ACS 3.4 or OpenACS 3.x if they
want to have finer grain control of the configuration of their site...
We could always assign it a new name, like ClosedACS 3.5 :)
Or Classic ACS 3.5 If we make the official name a little different, will the copyright matter?
How many ACS developers are out there? How many ACES developers are out there? And how many want to play ball with us?
Plan on our side still is to integrate whatever we can and release the stuff based on the ACES tarball I got from Sloan as the new stable release for ACS 3.x before christmas. Up til then I'd suggest populating the CVS with the ACES Sloan tarball and add whatever else we have (Intranet, Survey, you name it).
What do you think ?
P.S.: Concerning legal issues, well, what the heck. AD has abandoned ACS, Sloan probably would not mind to call it whatever we choose to name it. And as we repackage a whole lot of stuff together into a new release I doubt anyone would come after us.
Would you like the ACS 3.5 code to be based off of ACS 3.4.10 or ACES?
1. I would like ACS 3.5 to be based off of ACS 3.4.10 and I would not participate in development if ACES code were used
2. I would like ACS 3.5 to be based off of ACS 3.4.10 but I would participate in development if ACES code were used
3. I would like ACS 3.5 to be based off of ACES and I would not participate in development if ACS 3.4.10 code were used
4. I would like ACS 3.5 to be based off of ACES but I would participate in development if ACS 3.4.10 code were used
5. I don't care one way or the other, I would still participate in development
1. The code released under ACES contains the following new or improved modules in the form of packages:
News (also released separately)
Calendar (also released separately)
We can debate the modules one by one but I think most people will agree that it is valuable code and should be included in any new version 3 release. There is probably some work to be done to test that it can run without ÂeducationÂ installed but that was the intention when the work was done.
2. In my opinion, ACES can also contribute the concept of having ACS unpack into a portals based view that immediately shows people windows into the functionality of ACS. However, I think this might be worth having a poll on.
I donÂt think anyone thinks that the next release should unpack into anything that says anything about Âclasses or termsÂ. I certainly donÂt.
It should be a fairly small amount of work to turn ÂeducationÂ into yet another module that sits there until needed.
We do have some issues to work out between the various forks concerning permissions. I think the ACES team, Jade, and Malte have all come up with different solutions. Maybe we can have different permissions options turn off and on by parameters.
Unfortunately, getting there from here is still a little hard. I think that the fact that OpenACS supports Oracle is going to make the migration a lot easier (I don't have to port everything to both Postgres and OpenACS 4 at the same time).
I think once we get organized as a community, we should start developing a road map for getting all of us who want to get onto OpenACS 4. This will, of course, be beneficial for both the people already on OpenACS 4 and all of us stuck on ACS 3.4. We have a rough outline of a migration plan already (thank you, Andrew), and it looks like all of us could improve upon it and get ourselves all moved up to OpenACS 4. I think in the process we'll have to improve a lot of the modules available for OpenACS 4. For example, I will spend a lot of time getting the Intranet up to speed.
Ben, are we going to be able to prevent this migration gap from happening in the future? Is OpenACS 5 going to be totally incompatible with OpenACS 4? Are we even planning an OpenACS 5 at this point, with aD effectively out of the picture? Should I be starting a new thread for this?
It looks like the poll might not be necessary. Apparently, I misunderstood how different ACES was. If you all think it shouldn't break anything, let's start with that in the repository, and let's try to get a working ACS 3.5 going.
On the legal front, I'm trying to contact aD's lawyer to get an official blessing for us to use the name ACS 3.4. Otherwise, I propose we name is something else... Arsdigita Community System is okay, but we could probably do better. But I also don't want to distance the name from OpenACS, so we might just call it Classic ACS 3.5 or something similar.
I don't actually care, because performance isn't much of an issue for me.
I'm sure Ben would tell you this, but he (and the rest of the team and community) are pretty adamant about upgrade paths. We have made them for the 3.x series, we'll continue to do so for the 4.x series and on.
There's no OpenACS 5 formally planned yet, but with the experience we're gaining in OACS4, we sure are starting to form the ideas of what needs to be done for. But right now, all our focus is on getting 4 out the door.
I'm getting permission from aD's lawyer to use the term ACS. If that doesn't pan out, we can change the name.
How does this sound as a plan of attack
- Anyone willing to help out with maintaining the repository volunteer here. Say how much you're willing to help, what modules you're familiar with, etc.. I'll help, and I'm mostly interested in the Intranet module, and with migration. We may need a critical mass here if this is going to happen.
- Don has volunteered to set up the infrastructure on OpenACS. Who can provide him with a clean, working version of ACES he can upload?
- We're going to need a place to organize who does what, etc... Anyone have any experience with this? I don't have any experience managing an open-source project, but I'm willing to do what I can. Perhaps we can have our own forum set up here on OpenACS.org
- Once we have a repository set up, let's work together to start merging in our code improvements in a coherent way. We'll need to make sure we have clean upgrade scripts for anything that affects the database, etc... Anything I'm missing?
- Richard Buck