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

Mon Dec 29 09:29:32 PST 2014

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

On Mon, Dec 29, 2014 at 12:15 PM, Matthew Jones <matthew at longsight.com>
wrote:

> Yeah, I agree that sounds like the perfect scenario workflow and great for
> less frequent committers, but I'm thinking there will be at least a short
> term exception for those who previously had svn admin (full commit). Though
> likely the ideal is that that the svn admin group could be paired down once
> we see how it works but I don't think we have the capacity for a small (at
> the moment) group to both do the work in their own branch and have someone
> else manage their pull requests (even if it's themselves doing it twice).
> At least not until we see how the system is working?
>
> Is there really a significant process advantage for people we already
> trust over just having them commit directly? (I don't know, I've never
> worked in a large collaborative git project) I just see it as one extra
> unnecessary step right now. Maybe for a large feature that would normally
> have went in crucible, but not for a small bug fix that just needs to get
> in. So we'd have slightly different workflows for (for lack of better names
> at the moment) Sakai admin verses Sakai contributor.
>
> So for those who previously had svn-admin *and* have been active in the
> past 90 (?) days committing to svn. (Sakai Admin workflow)
>
> 1) They will be added with full write access to the github sakaiproject
> repository as admin's again to accept pull requests and push changes.
>
> 2) Those committers can just check out that repository directly, commit
> changes git locally, and push their commits when ready directly into the
> repository.
>
> 3) Everyone who didn't have svn-admin previously will need to follow an
> Sakai contributor workflow as described.
>
> 3a) If a commit is significant in scope, it should still go through the
> regular Sakai contributor workflow.
>
> 4) Ideally other pull requests in the queue will also be periodically
> reviewed by members of this Sakai admin group and committed
>
> Master will represent what was previously trunk. We're not moving any
> previous branches over to github, and when it comes time to branch for 11
> (in a month or so) we'll decide what we want to do about that.
>
> I agree that we'll continue to track bugs in jira, but any new contributed
> patches would probably be best to be attached as pull requests from a
> forked repository.
>
> On Fri, Dec 26, 2014 at 12:33 PM, Charles Severance <csev at umich.edu>
> wrote:
>
>> It occurs to me that we need a very simple page of how trunk committers
>> are to behave the "day after the move to git".  A quick scan of Confluence
>> suggests we do not yet have such a page as most of our work has been
>> getting ready.
>>
>> I am not talking about a whole gitflow explanation.  Just how to work
>> with trunk for the next weeks.  Something with the following outline:
>>
>> So you are a Sakai Trunk Committer and Need to Use GIT:
>>
>> (0) Make sure you have git setup and have a github account and have your
>> name and email properly set as git global variables on your workstation.
>>
>> (1) Fork the central Sakai repository to your own github account
>>
>> (2) Use your own copy of git to make your changes and test, etc.  You can
>> commit and push as to your own repo as much as you like.
>>
>> (3) When you are ready to "commit to trunk" send a pull request from your
>> repo to the sakai master repo.
>>
>> (4) If the changes are code you would have committed to the old SVN trunk
>> (i.e. just normal development) - merge your own pull request in to Sakai's
>> master
>>
>> (5) If the changes you are making are worthy of further review or
>> touching an are of Sakai that you do not generally work in - have someone
>> else review and merge your pull request.
>>
>> In general we trust Sakai committers to know the difference between (4)
>> and (5) - as time progresses, we will get better at this.  We will be
>> giving trunk committers broad access to the  sakai master repo and will
>> rely on the fact that we know when to merge our own requests and when to
>> request someone else to merge the requests.
>>
>> The super great news is that now folks who do not have trunk commit can
>> issue pull requests to the sakai master repo and we can get those changes
>> merged in a more natural way.
>>
>> We are continuing to use JIRA to do issue tracking - we will not be using
>> the github issue tracking.
>>
>> (Or similar)
>>
>> /Chuck
>>
>> On Dec 24, 2014, at 6:09 AM, Matthew Buckett <matthew.buckett at it.ox.ac.uk>
>> wrote:
>>
>> > I'll send this out to sakai-dev in a few of hours unless anyone has
>> > anything to add:
>> >
>> > Morning,
>> >
>> > We're planning on moving the trunk code of Sakai from SVN to GitHub on
>> > Monday the 29th of December. Work on the 10.x and 2.9.x branches will
>> > continue in SVN and nothing will be removed from SVN. The steps
>> > involved in this will be:
>> >
>> > - Monday 29th December
>> > -  SVN trunk folders in the main Subversion repository[1] go
>> > read-only. We will make all the paths with /{folder}/trunk/ in them
>> > read only so people can't make commits to these locations (also this
>> > won't include msub). This allows us to take a consistent snapshot for
>> > the transition to git and prevents commits getting left in SVN.
>> > - A conversion of read-only trunk folders is done and it is merged
>> > into one large project. The authors are updated with the details
>> > captured from [2]. Once a satisfactory conversion is achieved it is
>> > published on GitHub[3].
>> >
>> > - Tuesday 30th December
>> > - Everyone can check that that the conversion looks ok and things
>> > haven't got lost in the process. At this point we decide if new work
>> > continues in GitHub or if there are problems we have the option to
>> > rollback and continue to work in SVN by making the trunk folders
>> > writeable again and attempt a another conversion in the future.
>> >
>> >
>> > [1] - https://source.sakaiproject.org/svn/
>> > [2] -
>> https://confluence.sakaiproject.org/pages/viewpage.action?title=Migrating+from+SVN+to+Git%3A+SVN+trunk+committers+-%3E+Git+authors&spaceKey=PMC
>> > [3] - https://github.com/sakaiproject/sakai
>> >
>> > --
>> >  Matthew Buckett, VLE Developer, IT Services, University of Oxford
>> > _______________________________________________
>> > sakai-core-team mailing list
>> > sakai-core-team at collab.sakaiproject.org
>> > http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>
>> _______________________________________________
>> sakai-core-team mailing list
>> sakai-core-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>>
>
>
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>
>

-- 
earle,
asahi net int.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20141229/777a0496/attachment-0001.html 