[WG: Sakai QA] [Management] Release Process Proposal

Knoop, Peter knoop at umich.edu
Thu Jul 30 08:21:20 PDT 2009


One quick question/comment:  should this proposed process be considered in combination with the existing release guidelines, or is this a replacement?  For instance, I don't see any mention in the proposal about handling the end-of-life for past releases, (i.e., does 2.5 get eol'ed when 2.7 comes out, 2.6 when 2.8 comes out; does a release still get eol'ed after two-years)?  What about 2.4 support, or is it already considered eol'ed now that 2.6.0 has been released?

-peter

> -----Original Message-----
> From: management-bounces at collab.sakaiproject.org [mailto:management-
> bounces at collab.sakaiproject.org] On Behalf Of Clay Fenlason
> Sent: Wednesday, July 29, 2009 8:45 PM
> To: management at collab.sakaiproject.org; sakai-
> dev at collab.sakaiproject.org Developers; Sakai QA
> Subject: Re: [Management] Release Process Proposal
> 
> Just a reminder that I'm looking for comment through the end of this
> week, and if there remain no objections, plan to press ahead as
> outlined in the proposal.
> 
> ~Clay
> 
> On Mon, Jul 27, 2009 at 3:43 PM, Clay
> Fenlason<clay.fenlason at et.gatech.edu> wrote:
> > 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
> >>
> >
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
> 
> TO UNSUBSCRIBE: send email to management-
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"


More information about the sakai-qa mailing list