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

Mon Dec 29 09:29:02 PST 2014

Thanks Matthew B. ! Sounds like great progress today.

Do we all still think it would be good to have a check-in tomorrow
(Tuesday, December 30) at 10 am Eastern?

-- Neal

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