"The other would be to test and retag when we do a patchlevel release (like we did with 5.1.1). I am not sure that's a great solution since the whole point is to move away from monolithic releases..."
To elaborate: The purpose of the compat tag is to indicate when a package is released. The only way a file can get into a release tarball or into the OpenACS.org repository (for automatic install/upgrade) is if it's been tagged openacs-x-y-compat. That's the signal to the process that the package is tested and working for a given acs-kernel. The package should also be at a release version (ie, 1.0.0, not 0.1d), but the compat tag is the magic signal.
The only person who should be making that determination is the package maintainer. As release manager I serve that role for OpenACS core, and Tracy Adams handles it for .LRN. For core, that means that I check bugs, audit changed files, test the install, test an upgrade, and run the automated tests, for sixteen packages, for each dot release. For minor releases, there's quite a bit more work and we basically need a few bug bashes with 10 or more people to get a minor release out. .LRN covers many more packages and so, while Tracy can start with a released Core, she till has quite a bit more work to do to get a .LRN release out. Neither of us is likely to take over the job for the hundred other packages.
So what we need is for everybody who works on packages to take responsibility for deciding when a package is releaseable and doing the release work for it. It's only a few steps, and we're here to help, so I'm assuming that the problems are 1) this process hasn't been clearly communicated and possibly 2) people are nervous to take responsibility for a release, when it's safer to leave stuff at alpha or beta. So a big thanks to Jade (project-manager) and Dirk (calendar) for proving it can be done!
