Malte
I absolutely do no agree with checking in lower quality code than what is existing.
It should be reasonable to expect that once a package is working, new development will improve or add new features etc, without breaking existing functionality.
It seems there are 3 types of pacakges, 1) acs core packages, 2) the "important" optional pakcages, basically those that make up dotlrn, and 3) other optional packages not in wide use.
Now, there are always bugs, etc, so I don't expect perfection, but an effort to always check in working code would help.
This requires a little more effort on the developer's part, to design new features in smaller chunks that more a package forward a little at a time. The other option is to wait to commit until a package is tested, especially for 1) new install of openacs and 2) upgrade.
Another key is to add automated tests is you change existing behavior. The tests can confirm that the original behavior works, and the new feature also works.
These are goals, and guidelines, not requirements, but if the community can work towards these goals, the quality will improve.
Regarding releases 1) only the release manager should release OpenACS Core packages. Right now, we are calling Don the release manager, he took over when I didn't have enough time to manage the 5.2.3 release.
Thanks for stressing following the release process, I think it does work, and is helpful to remember to test a new install bfore you release.