Forum OpenACS Q&A: Response to Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST
- Move away from monolithic releases
Everyone agrees that we should not have single monolithic releases of all packages. It's unwieldy and makes the release interval too long. - Provide a Configuration Management tool
Important to have and hopefully someone will step forward to write one. It's not clear that it has a lot to do either with having a central package repository or whether we do monolithic code releases or not. - Provide a Central Package Repository
Again a good thing, someone should write one and fortunately APM is almost there. The metadata you would want to keep is in the info files already and all we would have to do is have a place to upload/post .info files and little bit of code to manage it. Unfortunately the current metadata in said .info files is complete crap. Hopefully if it meant something people would spend a few minutes cleaning them up.
On monolithic releases; I consider it a waste that we do not leverage CVS. If we used CVS properly and maintained a stable and dev branch we could do relatively frequent bugfix releases from stable and rapid cutting edge development on dev.
It is really little additional work and we would derive great immediate benefits, the biggest being that on stable we could limit data model changes to those with well tested upgrade scripts ensuring that production sites would be able to get bug fixes and be more confident about installing new packages.
Maintaining a central CVS repository makes merges dev<->stable much easier. and provides a great deal of transparency.
On configuration; ultimately, configuration is an awful lot more than just which packages you install and where you get them, and it's something we definitely need to think about. Although when I consider the state of the documentation I am not sure the effort is not better spent there rather than on a complex feature complete tool.
Also, From a purely technical standpoint I think I am leery of using a config tool which has Tcl code in it or depends on a lot of other tools to be installed. My preference would be for it to be data driven much like the current APM, although I guess I could be persuaded that the flexibility afforded by such a scheme might outweigh the dangers (the temptation to hack things in instead of using a clean Mist:: API, the risks of wiping out existing configuration data, obscure hard to reproduce bugs etc).
As for a package directory/repository, I think a central place to record where different modules live is great, and a download repository is great as well, but I think an awful lot of projects get by on CVS and tarballs and I think that's good enough for now.
All this is a long winded way to say that all the ideas are good ones and should figure in the plans for OpenACS but the problem is now (as it has been) who will write the code and is it what we want to spend those resources on. I don't believe either of the two code things are the most important things to be focused on, and I think we can avoid monolithic releases by simply overhauling some of our practices and educating developers about CVS. My list of major issues are:
- Documentation -- it is currently "not so good"
- Looks -- also generously described as "not so good"
- Bugs -- too many
