[cle-release-team] Release managers for 2.10?

Fri Oct 25 05:18:29 PDT 2013

I think that makes sense too. For Alpha bug fixes merge into trunk and Alpha, don’t wait for verification (but ASK for verification and have a Test Plan!).  Lock down for Beta.

As far as QA testing goes, I think we are going to have to rely primarily on regression/tool testing.  There are 500+ bugs from trunk which have not been verified. I’m just not seeing a way that QA can test all those in the timeline we have.  QA will need to prioritize testing.

https://jira.sakaiproject.org/issues/?filter=13763  - trunk fixes waiting for QA

I would be willing to monitor trunk commits and Jira to identify bug fixes which slip through the cracks. Perhaps we need a small team so that we will have a group responsible for merging in issues which are missed?

Thanks,
Neal

Neal Caidin
Sakai CLE Community Coordinator
neal.caidin at apereo.org
Skype: nealkdin
Twitter: ncaidin

On Oct 24, 2013, at 1:52 PM, Noah Botimer <botimer at umich.edu> wrote:

> Agreed. While an issue is swapped into RAM, devs will follow a reasonably involved process. Simplicity is key. 10 minutes to merge at the time of fix. An hour to do it later, swapping in from long-term memory, resolving issue status, destination, revision numbers, and interleaved commits. That hour is a bad tradeoff.
> 
> I would also like to see changelog-compatible commit messages or changelog entries get into this process. Easy in the moment; intractable in batch at release run-up.
> 
> Thanks,
> -Noah
> 
> On Oct 24, 2013, at 1:36 PM, Matthew Jones wrote:
> 
>> It doesn't even matter to me during alpha if they wait until it's verified. The workflow would be 
>> - Is it a bug? 
>> YES
>>   - Commit a fix to trunk 
>>   - Immediately merge the fix to branch
>> NO
>>   - Unless it's a pre-approved feature just leave it in trunk
>> 
>> Then QA can later verify it
>> - Is it still broken? 
>> YES
>>   - Re-open - Commit another fix to trunk, commit a fix to branch. 
>>   - If it can't be fixed we'd have to reverse merge it I guess?
>> NO
>>   -Great! Fix something else!
>> 
>> Essentially the branch wouldn't be completely stable until beta. Getting someone to commit, then come back and merge later is something that is unlikely to happen, but likely to happen at that moment. This is why we had to have branch managers.
>> 
>> 
>> On Thu, Oct 24, 2013 at 1:31 PM, Earle Nietzel <enietzel at anisakai.com> wrote:
>> Option #2 seems easy enough, just need to communicate that devs need to make commit after the issue is "verified" to the appropriate branch.
>> 
>> 
>> On Mon, Oct 21, 2013 at 12:54 PM, Matthew Jones <matthew at longsight.com> wrote:
>> Well, maybe that's one of the criterias for beta. We have to have someone named who will do merges. 
>> 
>> Option #2 is nice because even if developers *are* lazy and don't merge even when we remind them about it, we still can do it. In the case of option #1, someone on the release team will have to actively follow up and reverse merge unless we change global commits to only a much smaller group of developers who acknowledge that they understand the alpha policy who will avoid committing features to trunk and merge them in later after alpha.
>> 
>> 
>> On Mon, Oct 21, 2013 at 12:49 PM, Neal Caidin <neal.caidin at apereo.org> wrote:
>> How about we go with option #2 for alpha?  But we still need one or more volunteers for beta and beyond, it seems….
>> 
>> 
>> -- Neal
>> 
>> 
>> 
>> Neal Caidin
>> Sakai CLE Community Coordinator
>> neal.caidin at apereo.org
>> Skype: nealkdin
>> Twitter: ncaidin
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Oct 17, 2013, at 2:53 PM, Matthew Jones <matthew at longsight.com> wrote:
>> 
>>> So there were 2 options, leaving out the 3rd option which is the current process involving branch mangers doing all the merging and doubly QAing every change in the trunk and branch. This seems like it won't be realistic for an alpha since less people have stepped up, but possibly once more people get invested in the beta and merges slow down we will.
>>> 
>>> 1) On a specific day we say that trunk is now the alpha and will be the eventual beta, we will cut a release from trunk once some criteria is met 
>>>  - The identified criteria by the release team is all known blockers resolved and scope of release "frozen". All features don't need to be included but if a feature will be added, what it is and who is working on it should be identified by alpha.
>>> Pros: 
>>> - Nobody has to do any merges right now
>>> - We don't have to put up a separate nightly (We'd have to retire 2.8.x otherwise)
>>> - Only have to QA once
>>> Cons: 
>>> - Anyone with commit (global or local) could add anything that we might not have targeted for 10 (such as experimental features). I usually scan jira for new fixed issues but there's a good chance these would be missed.
>>> - Anything new experimental features that we don't want for 10 would have to wait a few months and sit in their own own branch/patch/github. This would be work to merge back into trunk later.
>>> 
>>> 2) We force (highly encourage) any developer who commit a change to trunk to also merge the changes to the branch at the same time for the entire alpha period.
>>> Pros: 
>>> - Still no new branch managers needed
>>> - Still should only have to QA once 
>>> Cons:
>>> - Probably have to get rid of 2.8.x and have a separate nightly 
>>> - A little more work for developers temporarily if conflicts come up to resolve, since trunk won't match the branch
>>> - Some change might have an issue requiring followup work requiring this to repeat
>>> - Some developers might not do this extra work
>>> 
>>> So it's really a trade-off between do we think all developers are more likely to make and hold their experimental changes off in a separate branches (to merge later) or do we think developers will be their own branch managers.
>>> 
>>> I feel like #2 is actually more likely.
>>> 
>>> 
>>> On Wed, Oct 16, 2013 at 8:06 AM, May, Megan Marie <mmmay at iu.edu> wrote:
>>> Which one from the thread are you suggest be considered?
>>> 
>>>  
>>> 
>>> From: cle-release-team-bounces at collab.sakaiproject.org [mailto:cle-release-team-bounces at collab.sakaiproject.org] On Behalf Of Matthew Jones
>>> Sent: Tuesday, October 15, 2013 4:01 PM
>>> To: Neal Caidin
>>> Cc: cle-release-team at collab.sakaiproject.org
>>> Subject: Re: [cle-release-team] Release managers for 2.10?
>>> 
>>>  
>>> 
>>> 2.8.x started with primarily Anthony doing Branching and releasing, but got a lot of branch contributions from the community (like 2-3 people). In the end it was Steve doing most of the work on 2.8.x
>>> 
>>>  
>>> 
>>> 2.9.x was mostly Sam on branches with Anthony picking up some starting about 6 months ago and Greg doing some earlier in 2.9.x. I did all of the releases after beta 02. 
>>> 
>>>  
>>> 
>>> Ideally for 2.10 we won't have as much work in releases after the initial time, but will possibly still have more work in branching, depending on what strategy we take for creating the branch.
>>> 
>>>  
>>> 
>>> Noah wrote about this last month in an email that ended that discussion, that we should probably consider.
>>> 
>>> http://collab.sakaiproject.org/pipermail/cle-release-team/2013-September/011107.html
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Tue, Oct 15, 2013 at 3:23 PM, Neal Caidin <neal.caidin at apereo.org> wrote:
>>> 
>>> So we need about 2 - 3 people? 
>>> 
>>>  
>>> 
>>> Release Manager
>>> 
>>> Helper to merge issues
>>> 
>>> Release Builder 
>>> 
>>>  
>>> 
>>> (apologies if this is the wrong terminology).
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>> Neal
>>> 
>>>  
>>> 
>>>  
>>> 
>>> Neal Caidin
>>> 
>>> Sakai CLE Community Coordinator
>>> 
>>> neal.caidin at apereo.org
>>> 
>>> Skype: nealkdin
>>> 
>>> Twitter: ncaidin
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> On Oct 15, 2013, at 1:50 PM, Anthony Whyte <arwhyte at umich.edu> wrote:
>>> 
>>> 
>>> 
>>> 
>>> None of which I am aware.
>>> 
>>>  
>>> 
>>> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
>>> 
>>>  
>>> 
>>> On Oct 15, 2013, at 10:46 AM, Neal Caidin wrote:
>>> 
>>> 
>>> 
>>> 
>>> Hi CLE release team,
>>> 
>>>  
>>> 
>>> Can you help me remember? Do we have any volunteers yet to manage the 2.10 branch (assuming we proceed)?
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>> Neal
>>> 
>>>  
>>> 
>>>  
>>> 
>>> Neal Caidin
>>> 
>>> Sakai CLE Community Coordinator
>>> 
>>> neal.caidin at apereo.org
>>> 
>>> Skype: nealkdin
>>> 
>>> Twitter: ncaidin
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> _______________________________________________
>>> cle-release-team mailing list
>>> cle-release-team at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 
>>> _______________________________________________
>>> cle-release-team mailing list
>>> cle-release-team at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>> 
>>>  
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>> 
>> 
>> 
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> 
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20131025/211e3367/attachment-0001.html 