[Building Sakai] 2.7 Release Discussion

[Clay Fenlason]

The 2.7 release process factored heavily into project coordination
discussions which book-ended the Boston conference, and I wanted to
try to represent consensus points (among those present in person) for
broader comment from those who couldn't attend. Time being as limited
as it is, I want to timebox a discussion period so that a clear
process can be settled on fairly soon. My current plan is to leave a
week for discussion, then craft a proposal which attempts to capture
points of broad consensus and then leave some further time (say, an
additional week) for comment on proposal particulars.  If we come to
an impasse a vote may be required, but the hope is that we won't be
forced into one.

The majority view of those present in Boston was that the soundest
approach to 2.7 would be to start with a maintenance release of 2.6 as
a foundation, and then only include new functionality which passed the
muster of a process making appropriate use of a new relationship
between the product council, the product manager, and the release
management team.  It was generally agreed that the product manager
should serve as the bridging agency between release management and the
product council, bringing matters to the council's attention where
needed.  The product manager would shepherd the process up until code
freeze, at which point the release management team would hold the
reins.

At a minimum, it was thought, any new functionality should be
documented before it could be considered for 2.7. It was proposed that
the "scorecard" criteria be used as a model for what the documentation
should include. [1]  New features and capabilities would fall into one
of two rough categories: light (eg new features to existing tools) and
heavy (eg entire new tools). Both classes would require documentation
in order to be considered, but lightweight additions could be reviewed
by the release management team and the product manager without
involving the Product Council except as a court of appeal.
Heavyweight additions would have to be reviewed by the product
council.

If project teams failed to provide documentation and/or respond to
issues that surfaced under review, then the general rule would be that
the new features would simply not be included in the release process -
a maintenance version from the prior release (where one existed) would
be used instead. On this point it was also suggested that we take
steps to allow tools - or at least some of the bigger ones - to
release on their own schedule. People were generally behind the idea,
but we didn't finish talking through what the practical implications
would be. I leave it as an exercise for the reader to press this point
further in the discussion thread.

The release management team would still be in a position -
independently of the product council - to exclude code from the
release process for critical issues of quality, security, etc. if they
were not addressed before a freeze date, or if they surfaced during
subsequent testing.

We did not settle on who we thought the release management team should
be, exactly, but the general idea was that it would at least include
the branch manager and the QA director, and draw upon other expertise
as needed (eg the security WG). Another idea would be to simply make
it the new maintenance team (cf the discussion thread from yesterday),
assuming one could be assembled in time.

Again, I'm sure I left points out, and corrections are welcome. I mean
only to start the on-list discussion, not provide the last word.

-- 
Clay

[1] See the blank scorecard at
http://confluence.sakaiproject.org/x/BwDi and a sample result by Mark
Norton for Sousa: http://confluence.sakaiproject.org/x/CQDi