[Building Sakai] 2.7 update

[Clay Fenlason]

A fair bit of work and discussion has been happening around 2.7
off-list and with particular project leads and teams, but it's
important to represent these on-list and clarify a few points.

It's beginning to look like the scope of 2.7 may be constrained more
tightly by available QA resource than past releases. The fixes going
into 2.6.x have been significant enough that QA for 2.6 maintenance
releases is non-trivial, and they need to be a priority. At the same
time resource is increasingly going toward Sakai 3 efforts, which is
also well and good. As things stand, however, the upshot is that
unless QA volunteers come forward in a strong way we may very well
face a number of decision points where new capabilities will not be
included in 2.7 because of a lack of people and time to test them
adequately. I hope that's an exhortation and not just a frank
appraisal.

BRANCH MANAGERS

We have three branch managers working together on various aspects of
2.7 right now. Anthony Whyte, David Horwitz (focussed on the msgcntr
branch), and Steve Swinsburg. We're very grateful for their efforts.

CODE FREEZE

The beginning of a shift toward independent component releases has
introduced some extra latitude in the schedule and coordination, but
there still needs to be a general freeze point where the changes not
included in an independent release are hardened into a 2.7.x branch
(in the interim Anthony has prepared a snapshot of trunk that's being
used as a QA branch for now). This freeze date and its negotiation are
owned by QA, and Nov. 20 has been set as the target. Pete will be
going directly to a few key players to pin down reasonable code vs.
message bundle freezes, and I expect he will have more to say very
soon.

INDEPENDENT COMPONENT RELEASES

We have now two big tools - the tools with the largest sets of planned
changes for 2.7 - moving toward independent releases: Forums and Tests
& Quizzes. Forums (or, more precisely, the msgcntr module) is the
first to have all its changes completed and merged into a branch, the
team from Michigan is putting finishing touches on the last remaining
UI merges as we speak, and we should have it on a QA server running
against a snapshot of trunk this week.

Although part of the ambition is to have project leads take greater
responsibility for seeing the changes they introduce tested and
documented themselves, we know that some extra support is going to be
called for until the new pattern is adjusted to, and so Foundation
staff will be playing a strong supporting role for this first wave of
tool releases.

Independent releases are not governed by code freeze in the same way
as other code changes, to the extent that they have already conducted
their own QA on the road to being released in the first place. Our QA
community may be able to work them into the rotation post-code-freeze
on a case by case basis, but again, the arbiter of this process will
be QA (with Pete as lead and point of contact).

NEW TOOLS / CAPABILITIES

This is something that I think hasn't been spelled out in the past, so
I'll venture it tentatively, but I think that new Sakai 2 tools and
capabilities that have worked their way through the product
development process should essentially be treated like independent
component releases as described above, as far as QA and release
planning goes. By the time they come through the product development
process they will - as the process has been defined - be ready for
release and maintenance.

So if you have a new component or tool (or even a very mature contrib
tool), for example, and you want to be in 2.7, the path begins with
incubation and the Product Council. [1]

POST-2.7

I expect there will be a number of independent releases of tools
tested against 2.7 but not included in the general release, most often
because QA couldn't work them into the schedule with available
resource. Yet these component releases will be relatively easy to add
to a base 2.7 as a technical matter. In fact, I expect release
documentation to highlight and link to some of these, as extra
components a deployer may want to bundle in.  So testing and
documenting independent releases will be put to good effect, even in
cases where tools had to be left out of the general release.

We are not assuming that there will be a 2.8 at this point. One
possible future is that the 2-series plays out the remainder of its
lifecycle in the form of additional component releases tested against
a stable 2.7.x. We'll see how things go, and how the community moves
over the course of the next year.

Corrections, comments and questions welcome as always.

~Clay

[1] http://confluence.sakaiproject.org//x/sgTtAw