I had a bit of a chat about this and basically you are correct. There will be efficiencies to be made where possible but little disruption to the self governance of projects. So this won't be a barrier to any move to Git.
cheers, Steve On 12/09/2011, at 12:48 PM, Eric Dalquist wrote: > I'll be interested to hear what you hear about the Jasig/Sakai stuff. The > talks we've had on the steering committee assumes that there will be work to > merge infrastructure but that project governance will remain with the project > steering committees, for example CAS3, mod_auth_cas, and phpCAS-Client have > all moved or are in the process of moving to GitHub. > > I'll look more into maintaining a read-only SVN clone of uPortal, potentially > in its existing location (this is complicated by the complicated nature of > the uPortal history). I'm guessing we could have a bamboo job that would run > git-svn post git commit to keep things in sync. > > -Eric > > On 9/11/11 6:00 PM, Steve Swinsburg wrote: >> >> Hi Eric, >> >> A could of responses inline: >> >> >> On 12/09/2011, at 1:01 AM, Eric Dalquist wrote: >> >>> Since the concerns need some actual discussion I'll see if I can answer >>> them here, my answers are in bold >>> Developer Familiarity & Conversion Lag >>> Primary concern with speed for applying critical fixes for a 4.0.1 release >>> I have done a test release using the maven release plugin against github >>> and the developer workflow does not change for cutting releases >>> There are ~ 6 very active committers on the project, I'll be sure to touch >>> base with each of them and get their vote before we make any move >>> svn:externals >>> Used by some deployers as an alternative to a vendor drop import >>> I'd like to get more insight on this approach versus doing a vendor drop >>> One option is for Jasig to maintain a read-only SVN clone of the git >>> repository if there is enough interest from those using svn:externals >> A subversion clone of the git repo would be handy, at least initially. It >> would actually tie in with 3 below, assuming the history is kept intact. >> >>> Local deployments using Subversion (if Subversion is their institutional >>> repository) >>> Process to merge fixes into local repository directly from the uPortal >>> repository? >>> Are there examples of a patch merging process that is specific to uPortal >>> using Subversion? >> Not specific to uPortal, but specific to Subversion. For example, we use the >> vendor drop method for major releases, however from time to time we want to >> pull in a patch that has been added to the branch. So we can simply grab >> that fix from the uPortal repository via an svn merge: >> >> svn merge --dry-run -c12345 >> https://source.jasig.org/uPortal/branches/rel-3-2-patches/ >> >> We could generate a patch, but it saves a bit of extra work. Having the >> subversion repo clone as in 2 above would allow this practice to continue. >> At some stage we may be able to move to a git repo, but not soon. >> >>> Sakai-Jasig merger >>> How will this relate to the merger and any broader SCM/Release management >>> strategy? (http://groups.google.com/group/jasig-sakai-collaboration) >>> As far as I know projects under a merged Jasig/Sakai Collaboration will >>> still be responsible for setting their own SCM and release management >>> strategies just as it is now under Jasig >> I'll be speaking with Ian Dolphin and Josh Baron this week, as they are in >> Australia for AuSakai 11. I'll try and get some clarity around this issue. >> >> From what I read in the Jasig-Sakai Common Foundation Value Proposition >> Document [1]: >> "Opportunities exist for bringing new and consolidated resources to bear on >> issues such as Quality Assurance..." - I'm presuming that will have some >> impact on release management. >> >> Further, "Consolidating our Technology Infrastructure - We expect to see >> cost savings from moving towards a common suite of centrally hosted >> communication and coordination tools (e.g. issue tracking, wiki etc.)." - >> It's unclear as whether or not that includes SCM. I'll try and find out this >> week. >> >> cheers, >> Steve >> >> >> [1]http://groups.google.com/group/jasig-sakai-collaboration/browse_thread/thread/29d561b06ae96966 >> >> >> >>> I'll continue to copy over content into the migration proposal wiki page. >>> >>> -Eric >>> >>> On 9/10/11 8:55 PM, Eric Dalquist wrote: >>>> >>>> I've moved the proposal into the wiki: >>>> https://wiki.jasig.org/display/UPC/Git+Migration+Proposal >>>> >>>> I tried to capture all of the concerns that have been raised in this >>>> thread though they could use more flushing out, especially the >>>> svn:externals issue. >>>> >>>> The wiki page also links to a test migration of the uPortal project to >>>> GitHub that I did this weekend: >>>> https://github.com/edalquist/uPortal-GitTest Please take a >>>> look around and let me know if you'd like commit access. >>>> >>>> Lastly one thing that the move to GitHub fixes is Fisheye. We were able to >>>> turn fisheye back on pointing to the Jasig SVN repository by having it >>>> ignore the entire uPortal source history. That's great for other projects >>>> but for uPortal it was a problem. We were also able to get Fisheye working >>>> against the uPortal-GitTest project: >>>> https://developer.jasig.org/source/browse/~br=master/uPortal-GitTest >>>> >>>> -Eric >>>> >>>> On 8/31/11 2:26 PM, Eric Dalquist wrote: >>>>> >>>>> I'd like to see uPortal's source code moved to git and hosted on GitHub. >>>>> There have been quite a few folks that have been working on uPortal 4, >>>>> uMobile or are otherwise interested that have asked about using git. >>>>> After looking into it a bit more I think it would be a very valuable >>>>> change for uPortal. >>>>> >>>>> For those not familiar Git is a distributed source control tool. What >>>>> that means is there is no true central repository like there is with SVN. >>>>> Developers don't really checkout some version of the code, they clone the >>>>> entire project when doing work. That doesn't prevent the convention of a >>>>> central repository which is what a site like GitHub provides. A place to >>>>> host a clone of the project that by convention we agree is the master >>>>> copy of the project. >>>>> >>>>> GitHub adds some very nice social-coding aspects to git. Primarily it >>>>> provides a VERY easy interface that allows anyone to clone a project, >>>>> make changes and commit them to their clone, then make a pull request on >>>>> the master project. Once that has happened a simple click of a button is >>>>> all it takes for any developer with commit access on the master to accept >>>>> the changes and merge them in. This process makes it very easy for people >>>>> without direct commit access to commit changes that are reviewed by a >>>>> core developer before merging in and significantly simplifies the work of >>>>> the core developers. >>>>> >>>>> When there was first talk among about switching I solicited feedback from >>>>> the Fluid project which recently moved from SVN to Git. I highly >>>>> recommend reading the resulting thread which highlights a lot of the pros >>>>> and cons http://old.nabble.com/Perspectives-on-Git-td31852449.html >>>>> >>>>> There is an eclipse Git Plugin, a TortiseGit client which is a clone of >>>>> TortiseSVN and I believe most other IDEs have either built in or plugin >>>>> support for git. >>>>> >>>>> Some other useful links: >>>>> Git for those without Version Control background - >>>>> http://hoth.entp.com/output/git_for_designers.html >>>>> GitHub's wonderful help documentation - http://help.github.com/ >>>>> TortiseGit - http://code.google.com/p/tortoisegit/ >>>>> >>>>> Some questions that I can try and answer before they come up: >>>>> - The uPortal code in svn at source.jasig.org would likely be left in >>>>> place, we would just make the entire /uPortal directory read-only >>>>> - We're going to filter out the documentation and website files that were >>>>> included in early versions of uPortal 2 to reduce the project repository >>>>> size. >>>>> >>>>> Since this is a big change (and since I'm going on vacation for 2 weeks >>>>> starting Friday) I'm planning on leaving this vote open for a while. +1, >>>>> 0, -1 to vote and if you vote -1 you need to include a detailed reasoning >>>>> for your -1 vote. >>>>> >>>>> -Eric >> >> -- >> >> You are currently subscribed to uportal-dev@lists.ja-sig.org as: >> eric.dalqu...@doit.wisc.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
