[sakai-core-team] Subversion -> Github Migration

Matthew Jones matthew at longsight.com
Mon Dec 29 11:22:44 PST 2014


It seems like 6 months from now would be too late for that type of
orientation. People wanting to commit will be already doing it by then.

And really everything anyway should need to know specific to Sakai would
should be able to be communicated by a few pages on confluence or in a
really short period of time. Everything else related to git in general is
too large a subject and too non-specific to learning that it seems better
to just self study on your own?

http://git-scm.com/doc
https://www.codeschool.com/courses/git-real
http://gitref.org/


On Mon, Dec 29, 2014 at 1:56 PM, Neal Caidin <neal.caidin at apereo.org> wrote:

> Please consider having some kind of pre-conference workshop at Open Apereo
> to orient the development community on the new process and tools?
>
>
> http://conference.apereo.org/news/nowopencallforproposalsforopenapereo2015apereosakaijasig
>
> Thanks,
> Neal
>
>
> On Mon, Dec 29, 2014 at 1:53 PM, Matthew Jones <matthew at longsight.com>
> wrote:
>
>> I was chatting with Earle, and I'm happy with whatever you're happy
>> working with. I think the uPortal is good, but dealing with the 9 step
>> process for branches and forks for major changes might be too much to start
>> out with for most work. So maybe the uPortal information just as it relates
>> to making a minor change, then expanding as we do have more significant
>> work and get to the point of branching.
>>
>> I like the detail they have though, going directly into the git commands,
>> we should have those details on our confluence.
>>
>>
>> On Mon, Dec 29, 2014 at 12:38 PM, Charles Severance <csev at umich.edu>
>> wrote:
>>
>>> Matt,
>>>
>>> I thought what Earle says below was what we agreed to.   Maintenance
>>> tasks can be pushed directly to sakai/master but bug fixes and feature
>>> requests go through PRs even if you approve your own PR one second after
>>> you submit it.
>>>
>>> I think we just need to get really good at forks, merges and PRs in the
>>> core group of committers so that we are well practiced and well prepared
>>> for contributions from those not in the group "formerly known as svn
>>> admins".
>>>
>>> But for maintenance tasks - definitely just checkout fix and then push
>>> directly to sakai/master or the appropriate branches.
>>>
>>> /Chuck
>>>
>>> On Dec 29, 2014, at 12:29 PM, Earle Nietzel <enietzel at anisakai.com>
>>> wrote:
>>>
>>> > Hi Matthew,
>>> >
>>> > I made some updates to the git workflow page in confluence...
>>> >
>>> > I would say that everyone follows that workflow...
>>> >
>>> > Typically the only people who do other tasks and would commit directly
>>> to sakai's github project are those doing branch management, aka merging.
>>> >
>>> > So for option 2 below it would be the same as just submitting a PR and
>>> approving it your self. Its fast and easy I think it would actually be more
>>> work to have to have a separate git clone and do some changes there and
>>> others in your fork.
>>> >
>>> > The rest of the work flow is the same, so with the workflow being so
>>> easy to just submit a PR and then click merge I don't see why people would
>>> want to commit directly.
>>> >
>>> > I am not saying we couldn't use the workflow you describe but think we
>>> should use the easiest workflow first and if we need to move to a workflow
>>> like you describe then we can do it later.
>>> >
>>> > earle
>>>
>>>
>>
>> _______________________________________________
>> sakai-core-team mailing list
>> sakai-core-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20141229/066d95ab/attachment.html 


More information about the sakai-core-team mailing list