Forum OpenACS Development: Re: Re: Re: Re: Re: OpenACS Roadmap 5.3

Andrew Piskorski

all package files would need to be moved both in CVS and in everyone's file systems anytime...

Yes, that's an issue. Filesystem is a tcl script run at upgrade time. CVS is an issue, for sure. Not insurmountable, but not trivial.

Some sort of text or Tcl file mapping each and every package to the "group" that it belongs to seems better to me...

In light of CVS, that seems a good compromise. But see my point on /contrib, below.

FWIW, I presented my view of an implementation, because I feel it very uncultured to present requests of free systems without providing an example. Truth be told, I am often criticized at the office for explaining examples rather than stating requirements.

You are very correct in saying the important thing is what people *do* with classifications. I am motivated by my experiences coming up to speed with ACS over the past six months. It is not at all clear which packages, other than acs-* are stable, etc. There are release numbers in packages, and there is dependency information. However, they don't convey the information that I believe a new programmer would need, namely, what can I count on/what to use now.

To your point, what would I *do* with such information? Or have done.

1) Decouple the core acs functions from the others in the release process, providing greatly reduced loads on the regression testing process, and providing for easier and cleaner releases of core function. Same ease of testing and release goes for other packages and package groups.

2) Provide for ease of importing a new package/packages. Having one dir makes it difficult to import from other CVS repositories.

It was this rooting around moving things from contrib into packages that was the root of my proposal. Moving them into packages breaks the CVS. Sym-linking them seems to work. But there is no way to cleanly deal if OCT moves the package to packages from contrib. If contrib packages can be made to appear to the package manager, then one can easily see how separation would work. The same issue exists if someone else chooses a name for a package that conflicts with a site-local package name.

Site-local, contributed, third-party packages should not clutter up the packages directory. Indeed one can argue they should not share the same namespace. But I said I wasn't arguing for that :)

3) Ease the retirement of deprecated packages, and the introduction of new packages. There are a number of packages in the distribution that are confusing, bulk-mail vs spam, address-book vs. contacts, portal vs new-portal.

How is one to know? Indeed, are they even kept up to date with the release? Should they be?

One can certainly root around in the OpenACS site to find these answers. One can also find conflicting answers. There is nothing so disambiguating as looking at the actual released code and seeing what's where.

Thanks for taking the time to discuss this with me. Obviously, I feel strongly about this, but I also understand the dangers in talking things into the ground. I hope I haven't done *too* much of that.

Cheers!