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 [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
