[sakai-pmc] Github migration

[Matthew Jones]

I think you outlined some of the good issues there.
(Comments on issues)
- I believe that we would make svn trunk read only *except* for a process
to synchronize periodically from github a few times a day. This is mostly
to facilitate ease of merging issues back to 10.x/2.9.x. If this it's
possible/easy to merge issues back without doing this, then I don't thing
it's necessary and we could just make trunk read only. (But I don't know if
it is)

- We have to figure out best practice for i18n. We aren't going to have
this complex i18n directory commit permission structure so we're going to
either have to take i18n pull requests or some (semi?) automated process to
commit i18n changes (like the trunk sync) maybe from crowdin.

Both of these processes would need to be written.

- msub for 10.x and before will not need to be moved. Anybody who is doing
a build off of 11/trunk will just need to fork it and we'll eventually
migrate naturally away from msub.

- I don't know what to do about contrib. We could leave it like it is for a
semi-long term, or we could force people out. I don't think the costs are
significant, but mostly it's just a few big projects anyway that get the
activity.

I also think we need more detail on the workflow, and we'll also have to
have a good communication in place that says when all of this will be
happening. Ideally we should target this to all happen before Apereo Camp
which will likely be occurring again in January, so I'd say before the end
of the year at the latest, but sooner starting the better. August is an
incredibly busy month for both Universities and SCA's, so I expect the
earliest would be around Educause at the beginning of October? That seems
like plenty of time to finish details, get communication out and actually
implement the plan.


On Mon, Aug 4, 2014 at 10:47 AM, Seth Theriault <slt at columbia.edu> wrote:

> On Mon, Aug 4, 2014 at 9:15 AM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>
> > It's probably time to revisit the github migration. I've thrown together
> a
> > skeleton page here:
> > https://confluence.sakaiproject.org/display/PMC/Github+migration
>
> As a point of discussion, we need to adopt a workflow model as part of
> the migration.
>
> Previous (limited) discussion/proposals/thoughts have been around:
>
> - Existing Jasig uPortal model (
> https://wiki.jasig.org/display/UPC/Git+Workflow)
> - Git Flow (http://nvie.com/posts/a-successful-git-branching-model/)
>
> Since Steve proposed the former and I proposed the latter, you have an
> idea where we stand, at least initially. I have to look at the uPortal
> one a bit more.
>
> Seth
>
> _______________________________________________
> sakai-pmc mailing list
> sakai-pmc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140804/5b997bd6/attachment-0001.html