[sakai-pmc] Github migration

Mon Aug 4 10:04:53 PDT 2014

Agreed -- this is one area where I think the move can really help. We should end up with a pretty standard workflow.

There are subtleties of how branches/releases are managed, but I think basic contribution will be typical:

1. Fork the repository to your user account
2. Push changes to a branch in your fork
3. Issue a pull request to the community repository

Whether the destination is master or some other branch is down to the specifics of the contribution and how much process we want to adopt.

One really nice thing is that Git/GitHub has brought a lot of familiarity to the base workflow across projects. For most projects, wherever the commits happen, they get into the main line(s) by pull request. This naturally democratizes and normalizes the contribution process: commit, push, pull request, merge -- whoever you are. Someone committing directly to the main line becomes a rarity, reserved for someone managing a special case. Whether "core" developers make branches in the main repository or a fork doesn't really change the process or raise barriers.

I mean this all to say: we will get a lot of mileage from the docs and culture already established, so our quick start guide should be very brief and easy to produce.

Thanks,
-Noah

P.S., I'm not convinced that we have enough volatility and release activity to make Git Flow pay off. It's nice and well defined but comes at a complexity price. I think we should start more simply and regularly ask ourselves if we are having to invent workflow -- if so, use it as a model.

On Aug 4, 2014, at 12:26 PM, Neal Caidin wrote:

> It would be nice also to have a "Quick starter's guide" for using Github with Sakai.  Simple steps for downloading and basic workflow for potential contributors. 
> 
> -- Neal
> 
> 
> 
> On Mon, Aug 4, 2014 at 12:18 PM, Matthew Jones <matthew at longsight.com> wrote:
> 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
> 
> 
> _______________________________________________
> sakai-pmc mailing list
> sakai-pmc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
> 
> 
> _______________________________________________
> 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/fba24ae1/attachment.html 