Forum .LRN Q&A: Notes on the .LRN release process (from Joel)

Passing this information along about the release process - thanks Joel for your help.

---
Hello interested .LRN parties:

I dropped in to a .LRN chat and this email is a resultant attempt to add some structure and clarity to the .LRN release process (if I can).

1) There is no real release manager for .LRN.  I'm the release manager
  for OpenACS, and in alpha and beta it wasn't hard to make .lrn
  packages as well.  At the technical level, it still isn't.  At a
  higher level, though, the difference between the two projects has
  become more obvious as we get closer to release.

2) My goals for OpenACS 5.0 release were to produce something that was
  useful to most users and had a measurable and determined quality
  level, and to build a process that not only worked better than what
  was used before, but was a foundation for ongoing improvement.

3) The main instruments used in OpenACS 5.0 Release Management:

  a) Release Criteria:
      https://openacs.org/projects/openacs/5.0/milestones
      I authored and maintain this list.
      The OpenACS criteria are not the same as the .LRN criteria.  We
      also decided to release 5.0 despite some issues that wouldn't
      affect most OpenACS users, but could affect .LRN users
      (translations, upgrade).  The automated test server has been
      very helpful in reducing the cost of the repeated testing that
      tells us our current status.

  b) Ongoing Triage of bugs:
      This entails looking at all incoming bug reports and adjusting
      priority, severity (if the reporter got it wrong), and fix by.
      This bounced around a lot - the OCT nominally has a rotating
      monthly triage duty, but that doesn't seem to have been
      super-effective.  Mostly random people went in (to the
      OpenACS.org bug tracker) and triaged from time to time - Talli a
      bunch last year; also I remember Tracy and Jeff doing a lot, and
      Lars.  I did a little.

  c) Decisions about Release Criteria:
      I made some judgment calls myself.  For bigger issues I went to
      the OCT (OpenACS Core Team), either with a TIP (a formal voting
      process - see
      https://openacs.org/forums/message-view?message_id=150299 for an
      example) or in the weekly meeting.  The Technical Advisory Board
      could do this, but its membership may need to be reviewed and it
      will need to have regular meetings.

  d) Bug Fixes:
      Many came from volunteers and by professional OpenACS coders in
      their "spare time."  Jeff Davis's fixes always seemed especially
      timely.  For .LRN, Collaboraid has some remaining contract hours
      to fix bugs.  The single biggest delay in getting 5.0 shipped
      has been getting bugs fixed.  (A side note: My OpenACS
      release management is primarily a personal role, not an employee
      role.  I started OpenACS RM before I started working at
      Collaboraid.  Lars and Peter at Collaboraid have put a
      tremendous amount of paid and unpaid effort into OpenACS 5.0,
      and Collaboraid has let me do unfunded OpenACS work on company
      time. We all have a vested interest in seeing our work and our
      clients succeed.)

  e) Actual releases:
      I documented everything necessary to actually generate a
      release, and Jeff Davis wrote automation.  It's a 10 minutes
      process, or 30 minutes with some manual sanity checking:
      https://openacs.org/doc/openacs-5-0-0/releasing-openacs.html

3) For .LRN, 2)a, b, c, and d aren't clear to me, so I'm not
  comfortable doing e.  Of course a lot of people are waiting for
  2.0.0 and I don't want to be a barrier for no good reason.  So, in
  the last .LRN chat, I offered to do e) as soon as someone from the
  TAB tells me to.

Also, some more detailed suggestions, prompted by:

[20:09:17]  <cmeeks>    Dee, how are you identifying the show
stoppers?
[20:10:02]  <dekane>    based on what i know we need to have working
for a launch here at sloan
[20:10:28]  <dekane>  i don't mean just showstoppers; i also mean
things that must work in order for users to do what they need to do [20:10:32]  <cmeeks>  are you indicating them in the bug tracker? [20:10:40]  <dekane>  not at this time [20:10:56]  <dekane>  but i can or i can send someone my list

For OpenACS 5.0.0, we used these rules:

if the bug isn't marked "Fix for Version: 5.0.0", we ignore it Hence, any bug that is relevant for .LRN 2.0.0 should be set, "Fix for Version: .LRN 2.0".

(Severity is an objective property of a bug.  We used:
  1. Critical - System crash, security violation, or data loss.
  2. Major - No workaround exists; because of this bug, a function
  cannot be made to work.
  3. Normal - The bug interferes with functionality but a workaround
  or alternative exists
  4. Minor/Trivial - The bug does not interfere with functionality
  (spelling errors, awkward presentation).)

Priority depends on resources available, etc.  With full-time coders on hand, Pri 1 would mean fix today, Pri 2, fix soon, Pri 3, fix before your next vacation.  I don't have a good rule for what this should be in the context of this open-source, volunteer effort.

Our release rules for openacs were:
All Severity 1 and Severity 2 bugs fixed or postponed.
All Severity 3/Priority 1 bugs fixed.

Effectively, any sev 1 or sev 2 fix for 5.0 bug was a beta and release candidate showstopper, regardless of priority.  Any sev 3 bug that we felt was also a showstopper we set to pri 1.

I hope this is helpful,

Joel