I'm moving discussion on the next .LRN release from the
registration-only forum at dotlrn.org to this one, and adding in some notes from discussion with Rafael Calvo.
What is the purpose of the next release?
What has to be present in the next .LRN release to make it successful? I still don't have a clear understanding. Here are some pieces:
- Get the bug fixes since the last release out.
- Get the packages up to a higher standard
- Incorporate the installers in the release process
- Add full support for more languages.
- Themes work. Exactly what is required?
- xhtml compliance. This is reportedly impossible to do across the board in time. How much, if any, will we aim for?
What am I missing?
Package Quality
At a minimum, we should try to bring all .LRN packages up to
OpenACS Maturity Level 3. There has been a lot of discussion about ".LRN-certified" packages, and it's time to codify that. Should .LRN-certified mean OpenACS Maturity Level 4? Should it mean ".LRN-certified", which is Level 3 plus some more stuff? Should .LRN have several maturity or certification levels? Here are some possible criteria to consider?
- Uses .LRN data model. (What constitutes the .LRN data model?)
- Compatible with portlets (or simply not incompatible with .LRN UI?)
- Meets Web Content Accessibility Guidelines 1.0 at
Level A
- Localized to list of 15/20 languages
- Has .LRN-specific documentation
What is the next version?
That depends on what changes we make. Probably it will be version 2.2.
When is the next version?
The goal is to release by September. There may be one or more intermediate releases. The next step is to develop release criteria, starting with
this example and adding items discussed in this thread. Heidelberg and has also submitted some requirements which I will add to the new criteria shortly.
We could test and release the current code (eg, the code on the openacs 5.1 branch); this could be .LRN 2.1.2. However, the numbering standard is to use the dot version (major.minor.dot) for bug/security fixes only, so the new release might more properly be .LRN 2.2.
When will .LRN be running on OpenACS 5.2?
Do we need this for the next release? Is it too much work to do this for the next release?
Release Committee
One of the key pieces of infrastructure for a release is a working group which represents all interested parties, makes decisions, and maintains coordination. Typically that would include:
- Project manager: (ideally project manager and release manager would be two different positions, but I'll fill this role for this group)
- quality control: (MIT?)
- development: (E-lane rep, MIT rep, others?)
- users: (representation by some or all of UNED, Vienna, Heidelberg, MIT, etc)
- Marketing: Rafael.
The duties of this group include
- Meeting regularly
- performing bug triage
- affirming or relaxing release criteria
If you know or are a good candidate for one of the roles, please post here.
The Release Committee will meet at least weekly; tentatively by IRC on Tuesday evening (US), Wednesday morning (Australia).
What is the list of packages in .LRN?
We have several lists of packages on OpenACS, and Rafael has been working on a spreadsheet for .LRN. I would like to put all of this together and track this information on OpenACS in a new package. How can we integrate this with the information in the
Repository, which is automatically generated from the code in CVS and thus potentially more accurate for its fields?
