[sakai2-tcc] Moving forward with releases

[Steve Swinsburg]

Thanks for the info Sam. 

Re 2.8.x all marked issues are now merged. I performed a code review and functional test for each issue before committing. All of these fixes are being pulled into our production build. I have some local QA resources to task for this upgrade so will report back on our progress.

cheers,
Steve






On 11/11/2011, at 4:03 AM, Sam Ottenhoff wrote:

> 
> Who do we have in branch management roles for both the 2.7 and 2.8 branches? I am hoping to finish all of the merges for 2.8 today:
> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12536
> 
> I won't be able to do 2.7, but there are only 31 outstanding resolved issues that have the merge flag set for a 2.7 merge:
> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12212
> 
> 
> I think umich *was* doing some 2.7 branch management over the summer. I know Indiana was doing it last year. I don't know anyone specifically named to either 2.7 or 2.8 branch management though and Anthony was doing most of it. I think there were 1-2 people that were going to be involve in 2.9 after it was actually branched. Maybe they can fill in for some of the 2.7 or 2.8 work.
> 
> 
> I was specifically named for 2.8 branch management and did the majority of the merges that went into 2.8.1.
> 
> Anthony was handling 2.7 merges.  There was mention that Lance @ rSmart would take over 2.7 maintenance merges, but there was no intention of doing another 2.7 release after 2.7.2.
> 
> Steve, thanks for the 2.8.x merges from the past week.  Please be careful and skeptical with some of the merge requests in the queue.  Several of the JIRAs are untested or without description how to replicate the original issue. Without QA capabilities on minor releases, I've leaned towards being skeptical for untested JIRAs.
> 
>  
> 
>  
> Now, something that really needs discussion is how these releases are performed. It should not take two days to learn a process simply to push out a release. It should be as simple as pushing a button, running a script or using Jenkins.
> 
> [snip]... 
> Horwitz said back at one time that we couldn't have kernel-util in shared because of the DB classes but never explained why. It seems like getting it out or not relying on it really needs to happen somehow.
> 
> That way, an indie can (in theory) be built off of the "lowest" version of purepoms that it's compatible with and it will be forward compatible with all other versions of Sakai. 
> 
> 
> This seems like our biggest impediment to reducing the release complexity.  Anyone that can chime in on kernel-util and our legacy reasons for kernel-util deployments to all projects would be appreciated.  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20111111/ce2a9f54/attachment.html