[sakai2-tcc] Moving forward with releases

[Sam Ottenhoff]

>
>
>> 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/20111110/d073fa1f/attachment.html