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

Mon Dec 29 09:15:40 PST 2014

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