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

Matthew Jones matthew at longsight.com
Mon Dec 29 10:12:54 PST 2014


I'm open to seeing how it works. I just feel it's going to end up with a
lot of forks getting ahead of master in some places and a lot of patches
getting missed because people forget to pick the button or request a pull
request, resulting in merge conflicts. And we don't have anyone in a
project maintainer role to keep these flowing along. It's a significant
workflow change for everyone. Then it ends up being back on us to try to
track those down if we want (or care) to get those included.

Personally I don't remember specifically agreeing to such a change in
workflow from centralized [1] to forking [2], but I do remember discussing
with Steve about reviewing the (much more detailed) uPortal (
https://wiki.jasig.org/display/UPC/Git+Workflow) workflow which does much
better describe this forking model for both those who have commit and those
that don't.

Committers : https://wiki.jasig.org/display/UPC/Git+Workflow+for+Committers
Non Committers:
https://wiki.jasig.org/display/UPC/Git+Workflow+for+Non-Committers

These both look fine to me, and I'd agree with something like this.

[1]
https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow
[2]
https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20141229/b71b9cc7/attachment.html 


More information about the sakai-core-team mailing list