Forum .LRN Q&A: Notes on the .LRN release process (from Joel)
---
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