Forum OpenACS Development: Removing packages from acs-core that we don't use/need

I am about to remove acs-workflow from acs-core as it doesn't seem to be needed anymore and has been superseeded by the workflow package.

Glancing over the other packages I found acs-content and acs-util. It seems nobody uses acs-util so I am assuming we shall remove this from acs-core too? Maybe even move it away from the packages dir? Should all applications reside in the packages dir or should we move applications away (to contrib/packages?) that aren't really core to what we are doing and aren't being actively maintained or used? Bascially if a package isn't part of some dotXXX (ecommerce could be one configuration) packaging strategy that we have I think I would rather see it moved away from the packages dir.

I think it would be nice if we had some way of indicating which packages are actually core to OpenACS and are being maintained. I guess this maybe falls under the dotLRN, dotWRK etc. packaging effort that we have started. What I am wondering is how a beginner looking at the long packages list is supposed to figure out which packages are high quality and actually worth installing. Also how does a beginner know that the bboard package is superseed by forums? Another duplication of functionality is photo-album and photo-album-lite.

Can we put together an OpenACS packages page (with ETP) where each package has some kind of status and a maintainer? I think that would be very helpful.

Moving things around is not going to help.

Offering a package repository like Ybos has running here:
http://developer.ybos.net/modules/?distribution=all&view=all
on openacs.org (with additional info) might (it would certainly make it more likely that someone pick up an old package, dust it off, and use it).

Other options: add additional information to this page:
https://openacs.org/doc/openacs-4/ or add a little package status box to the individual package's documentation.

Starting with a package status page using ETP would be the first step (a survey if you will), but not the solution.

Collapse
Posted by Don Baccus on
Peter and I exchanged private e-mail.  Please keep in mind, folks, that the long-standing plan has been to break away from monolithic releases and to design and implement a good repository structure for asynchronous package releases for OpenACS 4.7.

As far as duplication of functionality and all that I think that the time to tackle that is when we tackle the other issue, because they're related.  We'll also have a contrib repository for user add-ons that aren't supported by the community at large.

I know things are still a bit ragged but our focus has to be on getting 4.6.2 and dotLRN 1.0 out the door and stable, and to then switch to moving forward on 4.7 ASAP which includes tackling packaging and related issues.