Forum OpenACS Improvement Proposals (TIPs): TIP #47: (Implemented) Package Maturity Standards
Each package has a maturity level. Maturity level is recorded in the .info file for each major-minor release of OpenACS.
<version ...> <maturity>1</maturity> </version>
Maturity level is visible in the Installer and when browsing the repository.
- Level -1: Incompatible. This package is not supported for this platform and should not be expected to work.
- Level 0: New Submission. This is the default for packages that don't have it set explicitly, and for new contributions. The only criterion for level 0 is that at package is uploaded into the repository.
- Level 1: Immature.
- Meets Level 0 Criterion
- Current release has no open priority 1 or priority 2 bugs.
- Has been available in a final major-minor release for at least one month and major-minor-dot release for one week.
- All API functions have documentation
- Source code is available at published location.
- Level 2: Mature.
- Meets all Level 1 criteia
- Has installation guide and user documentation
- OCT member verifies no serious deviations from general coding practices
- Has no namespace conflicts with existing level 2 packages
- Level 3: Mature and Standard.
- Meets all Level 2 Criteria
- OCT member verifies code meets published coding standards
- Contains no non-internationalized text
- Available on all supported databases.
We don't have any objective way to determine the quality of our 100+ packages
Volunteers will have to do ongoing work to determine maturity.
- The APM needs to parse and display this new information when looking at local packages and when looking at lists of packages to install. A volunteer needs to do this.
- The repository generator must parse and display this new information so that it is visible when browsing the repository. I will make sure this is implemented.
ChangesCorrected example to match implemented code. JoelA 30 Nov 2004. Old example was
<maturity> <platform id="openacs-core" version="5.1"> <level descr="Mature">2</level> </platform> </maturity>
I like the idea but am concerned about the implied amount of effort and want to get a better handle on how much is involved.
- We don't have a use for the id field
- The version field is redundant because it's in the same file already in three places. Instead of having three different blocks with different versions in one file, we should have one block in each different version of the file.
- The description should be a message key, so that it can be internationalize. We'll code the mappings of integers to message keys in the page code.
Since you seem to be revising your TIP, could you please post the modified XML that would have to be implemented?
Also, with respect to the TIP process, does this mean a revote is in order (once your modified version is posted)?
<maturity>1</maturity>I think we're going to run in changes between the approved TIP and the implementation from time to time. It can happen when the TIP is incompletely specified, which we should fight hard against because incomplete specs usually go hand in hand with underestimated costs and consequences and delayed implementation. It can also happen when there are problems or obvious changes with the TIP that become apparent during implementation.
Here are two options on how to handle this:
- Changes must always be posted in the original TIP, and that posted changes are legitimate amendments if they are not vetoed within 1 week. Veto means that the original TIP must stand or be re-TIPped.
- Changes must always be posted in the original TIP, and must then be approved according to the same rules as TIPs - two yes and no no in a week, or full vote in two more weeks. Veto or negative vote means the original TIP stands or must be re-TIPped.
Another option would be to include bug tracker in the process so that the number of open bugs influence the maturity level as well.
The danger I see with the proposed maturity level standard is that it lacks of some automation. This will results packages to reach a high level during their life cycle and stay at a high level even if the code base get's messed up over the time.
Therefore I would suggest that the level is set involving the testing results and the bugs in bug tracker.
Only packages that pass the tests should go into the release or beta versions, others should go into something like the HEAD version.
The package manager could as well use categories to flag where the packages "belong to" (core, dotlrn, commerce suite, project, ...). This would be an alternative to the discussion, whether the packages directory should be restructured (see 5.3 roadmap discussion). This would help especially beginners to see what's there and what is ready to use for what purpose
Differences between local and CVS version would work if CVS diff was reliable, but somehow I never got it to show me differences when something changed on the server side. Any pointer, so someone can write a page which takes the package-key, looks for the branch TAG in the CVS directory (or for something in the APM which stores what repository to use) and then execute the CVS diff and display the result on the page?
Automatic commit is nice, same is regression test, would be interesting to see it in action.
As for the categories, this requires a TIP but should be implemented in 5.3. It should be a parameter like “< belongs_to name=dotlrn version=2.2>”. No need to restructure the packages directory then.
Additionally, we should have a switch which allows us to mention if a package uninstalls correctly once installed. Though this would probably a good maturity requirement, the conditions in packages and the linking between packages can sometimes prevent this form happening (I’m just thinking about people uninstalling project-manager if it was running in a mixed .LRN/contacts/invoices environment. Cascading will most likely break).