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

[David Haines]

As pointed out in the release proposal there are a couple of different  
kinds of changes that can end up in a release.  Some are incremental  
changes and / or fixes that aren't controversial should be in a  
release soon as general improvements.  There are also bigger changes  
that require more design and thought.

It seems that the 2.7 release will have the first kind of changes.  It  
also seems like over-planning to work at try to find out what ought be  
in 2.7 and then plan dates from there.  It would be more realistic to  
establish specific dates based on the practicalities of doing a  
release and make it clear to the community when changes need to be  
ready to get into the release cycle. That allows for groups to plan on  
their own without an explicit or implicit expectation that the Sakai  
foundation will be orchestrating the work.  If a group want's to have  
their changes in the release they know the deadlines, if one group  
wants to help out another with QA or such they will be able to know  
when their efforts are likely to be needed.  This doesn't mean there  
isn't release management, just that it is incumbent on community  
members to take the lead on getting a specific change into a release.

For a release with bigger plans it makes a lot of sense to make the  
release date dependent on the necessary set of features being available.

- Dave


David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines at umich.edu




On Jul 27, 2009, at 3:43 PM, Clay Fenlason 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"
>
>