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

Clay Fenlason clay.fenlason at et.gatech.edu
Thu Jul 30 08:25:39 PDT 2009


It's not meant to replace what it doesn't address explicitly.  Not
meant to be comprehensive about release policy, in other words, just a
way forward for what's next on deck.

~Clay

On Thu, Jul 30, 2009 at 11:21 AM, Knoop, Peter<knoop at umich.edu> wrote:
> 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