Forum OpenACS Development: Requirements for package registry package

Request notifications

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
  • 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 host
  • The package holds a list of openacs packages
  • 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 bugtracker
  • all bug data is derived from 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
Posted by Nima Mazloumi on
Is there a link to that package?
Posted by Joel Aufrecht on
No, somebody has to write it first.
Posted by Jade Rubick on
What is the last releaser? Is that supposed to be the package maintainer?

Can we use normal permissions to decide who can create, edit, and delete entries?

Otherwise, this is fantastic, and thanks for volunteering!

Posted by Malte Sussdorff on
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?
Posted by Andrew Grumet on
Suggested requirement:

  • Package list is available to unathenticated Web clients in a reasonable XML format, perhaps a format that looks a lot like a .info file.

Posted by Andrew Piskorski on
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.

the distributions stuff is done:

additional enhancements will come... ;o)