There have been several attempts to maintain a list of packages, the most recent being OpenACS Packages and the .LRN package spreadsheet. The manually maintained lists fall out of date, and don't have enough useful information. The automated lists (repository, Bugtracker) are current, but not well integrated. These are requirements for a package which tracks the status of all packages; Rocael's team has tentatively volunteered to implement it.

• The package runs on openacs.org
• Any modifications, configuration, or customization required to run the package are made through a web interface and stored in the database, not in the files on the openacs.org host
• The package holds a list of openacs packages
• OpenACS.org registered users can create new package entries.
• The fields for each package include
  • name
  • code name
  • Description, from repository
  • version, from repository
  • release date, from repository
  • last releaser, from repository
  • non-closed Pri 1 bugs
  • non-closed Pri 2 bugs
  • non-closed Pri 3 bugs
  • non-closed Pri 4 bugs
  • closed bugs, drived from openacs.org bugtracker
• all bug data is derived from openacs.org bugtracker
• All "repository" data is derived from the .info files in source control, either directly or through the repository builder process, and is at least as current as the last repository rebuild
• All package data can be viewed in a sortable table.
• Collections of packages can be identified as distributions, such as openacs-core and dotlrn-all.
• A viewer can limit the list of packages to those of a single distribution

No, somebody has to write it first.

Should we add the maturity level along with the database(s) supported and whether it is I18N or not (maybe even with the languages available, taken from the translation server). Furthermore the translation server for this package should be stored somewhere (or none if there is none). Last but not least, how about the maturity level?

That sounds very, very useful.

In this package-registry package', please be sure to include a spot for some sort of manually-maintained Wiki-like content about the package. The most important info to know about many packages is, "Why the heck should I use this? How does this relate to other packages? Is it deprecated or current, and what sort of ongoing development work is happening or planned for it?" And that info can only be provided by human-maintained content.