[sakai-pmc] Github migration

Wed Aug 27 15:18:22 PDT 2014

I think that moving to git will just be a different model than we have now.

Now we've always had trunk be the "wild west" and anyone with trunk where
anyone with commit can commit almost whatever they want (at most times) and
it will appear every 4 hours on nightly. Moving to any typical git model,
this won't happen as most likely the pool of those who can perform merges
would be smaller and master would (ideally) only contain pull requests that
have been verified by someone who isn't the committer. This is kind of like
how our branches (10.x) work now.

In this model they have a development branch that has a lot of work going
on but not very much in master
http://nvie.com/posts/a-successful-git-branching-model/

So I think our biggest problem will be how are we able to see/demo the
latest and greatest work in progress changes in development if we are
working on it in our personal user accounts. How will someone be able to
test it so they can do the pull request? It seems like there would have to
be some branch (either develop/master/whatever) that is always updated like
trunk and is more accepting of pull requests. (Maybe even to the point of
being nearly automatic)

I think everything else would be in the git svn crash course. :)
http://git.or.cz/course/svn.html

On Mon, Aug 4, 2014 at 1:04 PM, Noah Botimer <botimer at umich.edu> wrote:

> 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/20140827/f87963f3/attachment.html 