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

Matthew Jones matthew at longsight.com
Thu Oct 24 10:36:43 PDT 2013 

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20131024/f04edf20/attachment-0001.html

More information about the cle-release-team mailing list