[WG: Sakai QA] Release Process Proposal

Clay Fenlason clay.fenlason at et.gatech.edu
Mon Jul 27 12:43:40 PDT 2009


After having a couple conversations offline, it sounded to me like it
wasn't hard to get the wrong idea about the notion of the release
management team, so I'm going to hunt for some better language, but I
thought I'd do that by thinking out loud in this thread.

The main purpose of the close collaboration of the product manager and
this formal release team ahead of code freeze is, in my view, to
develop an achievable plan for release management and testing. It's to
survey all the development work on the table, get a sense of what the
associated risks are, see that they have time to be adequately tested,
documented, and lead to a solid release.  But the focus is on devising
a credible plan and publishing it for the community ahead of time, not
on approving or rejecting development work.

Now, if it turns out that a credible plan is impossible in a given
timeframe and with the array of new development work on the table,
then that will have to lead to another conversation which the release
team isn't going to settle it by fiat.  Its role will be to surface
this information for a broader consensus to be reached, basically
saying, "We don't think this can be done, and so we either need to
look at adding a month or two to the release schedule, or postponing
some planned features, but something needs to give."  Leaving aside
the details of what happens then, the important point is that the team
is meant to bring greater transparency to these issues up front, and
reduce the risk of surprises well into the process. (As a
side-benefit, I think the community should get a fairly decent
projection of "release notes" even before formal QA begins, which
should put their respective training and support staffs ahead of the
game)

After code freeze there may be decision points along the way where
action needs to be taken based on issues of code quality, etc. In such
instances we don't want a discussion with no clear resolution, nor do
we want expertise overruled by influence (or whoever happened to show
up for the call that week).  In my view, we want a technical
decision-making process like the balance achieved by Apache's
processes, where consensus is sought, yet which is also bracketed by
formal mechanisms for reaching resolution. To that extent, then, a
formal team.

Finally, the initial set of 3 team members is to me still very much
just a minimal starting point, and I expect the group to grow quickly
by meritocratic means, where again I think the Apache process has
useful rules of thumb for expanding this kind of technical governance
in a meaningful way. The proposal linked to below would task the
initial 3 members with proposing how they think that should run.

~Clay

On Fri, Jul 24, 2009 at 11:20 AM, Clay
Fenlason<clay.fenlason at et.gatech.edu> wrote:
> I'd promised a week ago a specific proposal for a release process,
> building on discussions at the project coordination meetings and
> on-list [1].  I now have a draft of this proposal on Confluence, which
> focuses on the release process for 2.x over the next 10-12 months:
>
> http://confluence.sakaiproject.org/display/MGT/Release+Proposal+2009 [2]
>
> My plan is to continue to develop/refine this proposal with comment
> from the community over the course of the next week, and if no
> 'blocker' disagreements emerge in discussion, I will act to coordinate
> the 'Next Steps' laid out in the proposal fairly quickly. Some of the
> details in the proposal can be revised as we go, but I'm eager to get
> started and allow as much time as possible to follow through on its
> aims, so I'll urge eveyone to take a close look and offer up questions
> and comment as soon as they can.
>
> ~Clay
>
> [1] http://www.nabble.com/-Building-Sakai--2.7-Release-Discussion-to24541385.html
> [2] http://confluence.sakaiproject.org/display/MGT/Release+Proposal+2009
>


More information about the sakai-qa mailing list