[WG: Sakai QA] Request for inclusion in 2.6.1: SAK-16416

Fri Jun 5 07:19:43 PDT 2009

I'm not going to get into the procedures (that's up to the QA group),  
but let me outline a few things we've discussed in the past:

* QA is a (possible the most important) bounding factor on how many  
and which issues can going into a maintenance release. If we try to  
include everything that is fixed we create a large QA testing effort.  
Especially regression testing. This delays maintenance releases.  So  
there is an important balance between the number of things we include  
and the speed with which we get maintenance releases out the door. The  
more issues fixed, the longer it will take.

* It is my view that a maintenance release that introduces regressions  
is a very bad thing. So they need to be well tested. Unfortunately the  
lack of unit test coverage (or automated testing of any kind) in the  
2.x code base makes regression testing a manual process.

* To reduce the surface area for testing we (the foundation) has  
adopted a strategy of targeting a limited number of components for  
maintenance releases. We test those few well and then cut a release.   
Hopefully we hop onto the next set of components and can cut a second  
maintenance release "soon" after.

* Security issues change the schedule.  They need to happen quickly  
and so we may change our plans entirely based on the severity of the  
security issue and how close we are to cutting a release. And when one  
of these issues is involved it will now mean (usually) simultaneous  
releases on the 2.5 and 2.6 series (at least).

Now we haven't been fully successful in executing this approach for a  
variety of reasons. And it is only a good idea to limit the components  
involved if, in fact, we can get maintenance releases out fairly  
quickly I'm expecting Pete P to get things moving more smoothly.  But  
right now the community is placing too much reliance on the  
Foundation. We simply need some help :-).

Mostly this means help testing maintenance releases. Those who want to  
help test will certainly get a bigger voice in what issues/components  
are addressed first. Makes sense, yes?

Another issue is the work involved in release management. It is  
increasingly the case that the work of release management has been  
taken up by Anthony.  We could really use some help with that. I'd  
love to have someone in the community start to manage the maintenance  
releases--usually the .0 release is the hardest and once things are  
set up, the maintenance release process is much less burdensome. Any  
volunteers to manage the upcoming maintenance releases for the 2.6 or  
2.5 series?  Anthony will certainly guide you through the first one  
and be there to assist.....

Best,

Michael

On Jun 5, 2009, at 15:06, Noah Botimer wrote:

> This raises the question of issue targeting again. We have a number
> of issues fixed and verified that we would like to defer beyond
> 2.6.0, but don't have anything aside from the comments to denote
> that. We have tried multiple approaches and found additional fields
> to be confusing or ineffective.
>
> My confusion is that the issue is Closed, fixed in trunk, and marked
> Merge for 2.6.x, but we're putting an indefinite hold on known,
> desired action. How do we deal with this conflicting information,
> find the issue later, and know what to do then?
>
>
> Should we be marking v.next items when they come up? Specifically,
> should these items be marked as 2.6.1 [Tentative] as well as 2.7.0
> [Tentative] and left as Open or Resolved until merged into the
> destinations?
>
> Should we also take better advantage of the "release branch" idea?
> That is, we have a 2.6.0 branch made already (as of moving to Release
> Candidate) to allow for exactly this kind of thing, where we can
> "open up" 2.6.x  for immediate merges and pluck the few that taint an
> RC into 2.6.0.
>
>
> My apologies if this is misguided, redundant, or naive. I just have a
> perpetually hard time reconciling real practice with the guidelines
> in Confluence. It's hard for me to know if there is work people
> expect me to do and the right steps to follow if there is. I will
> gladly welcome comments or guidance.
>
> Thanks,
> -Noah
>
>
> http://confluence.sakaiproject.org/confluence/x/CSE
> http://confluence.sakaiproject.org/confluence/x/NgBL
>
> On Jun 5, 2009, at 4:54 AM, Jean-Francois Leveque wrote:
>
>> Hi all,
>>
>> SAK-16416 is only a Major so it should not delay the 2.6.0 release
>> but I
>> think it deserves inclusion in 2.6.1 after being merged into 2.6.x.
>>
>> Cheers
>>
>> J-F
>>
>> _______________________________________________
>> sakai-qa mailing list
>> sakai-qa at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>>
>> TO UNSUBSCRIBE: send email to sakai-qa-
>> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>
> _______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-- 
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska at sakaifoundation.org
phone: +1 510-931-6559
mobile (US): +1 510-599-2586
skype: mkorcuska