Currently the OCT has started a discussion on the maturity of the OpenACS code base and the expectations of CVS HEAD. Here is my take on this (and hopefully non OCT members will give their comments as well).
On using code from CVS:
Use CVS at you own risk. Always. Do not assume CVS code works. If you use code from CVS, it will most likely fail. If it fails, file a bug report. Wait for the bug report to be dealt with, then try again.
On releases (read: -compat flag) and maturity level:
We have releases of OpenACS Core and packages. These are clearly marked by the openacs-5-2-compat flag and show up in the OpenACS Repository. If a developer makes the effort to mark a package compatible to a certain version, he knows that it will work and apparently has tested it.
The maturity level is for a package *at a given time*. You should always be able to commit a package in a lower maturity level than it was before, as long as you do not release it.
This method has a couple of advantages:
A) You do not have to fork to /contrib if you have new ideas and they might not adhere to the standards of the current code maturity immediately.
B) We have package releases. Only a released package is supposed to work. Though this reduces the number of packages available, it increases the quality of the code and the user can be sure that someone is looking over the package.
C) It reduces the need to merge from contrib to release.
D) Developers are able to commit code early on and exchange code. I can only say, if stricter rules with regards to HEAD commits had been into place, contacts and project-manager would never have been committed from our side as they are still under heavy development and we only have time every few months to test a proper release. Which would have made the exchange with Matthew and Alex hard to non existent.
For the future I suggest:
A) Post clear guidelines what to expect from OpenACS CVS and from the released packages. This is the following:
- If a package shows up in the OpenACS Repository (not CVS) then a developer has decided that it is save to use in the maturity level given to it. No released package should have a maturity level < 1.
- If a package resides in the CVS repository of the currently released branch of OpenACS, then the chances are high, that the package works in the maturity level given to it. This has not been proved by a developer yet though.
- If a package resides on CVS HEAD, then chances are high that it breaks. OpenACS core package will be cleaned up and tested before the release of the next version. Before that, using OpenACS Core from HEAD is for testing purposes only and at your own risk. We encourage you to do this though in your development areas once the previous branch has been declared final.
- Any package without a maturity level is not supposed to work, regardless where it resides.
For CVS commits we should encourage / enforce to our abilities the following rules of conduct:
- If you work on a package and think your changes reduce the maturity, decrease the maturity level. DO NOT RELEASE.
- Only release packages if their maturity level matches the level of the version before and you have tested that it works.
- Only release a package if you are willing to fix bugs that did not exists in the release before (read: that have been most likely introduced by you).
- Do everyone a favour and try to follow the release guidelines for OpenACS Core before releasing a package on your own. After all, if critical or serious bugs exist, how are you able to use the package.
- Before committing your code to the CVS repository, make sure the package you commit to has someone else (preferably from the OCT) marked as "code reviewer". A code reviewer will take a look at your CVS commits and make sure no accidental commits sneak in. The code reviewer should be stated at the Package page in XoWIKI.
- Before releasing a package, make sure that the XoWIKI page for the page is filled with sensible data (e.g. the name of the reviewer). Furthermore, detail out (and if only brief) what you changed for this release. If you can't remember, feel free to state "and much more...", but at least make others aware that a lot has changed.
- Do not release OpenACS Core packages, unless you talked to the OCT before it.
- Make use of dependencies and clean them up before a release.
On code reviewer:
A code reviewer is a person, who is willing to take a glance at the CVS commits of a package and make sure no custom code sneaks in by accident or the new code is not documented enough to make sense. The code reviewer is not supposed to test the package or even use the package himself. A code reviewer can always drop his reviewing obligation at any time. It is in the responsibility of developers who want to commit a package, to find a code reviewer first. The OCT should be helpful in finding a code reviewer if initial tries by the developer fail. The OCT is not obliged to become code reviewers for all packages, though Code Reviewers for Core packages have to be members of the OCT.