Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
Great, so with that support I need anyone that has committed to uPortal in the past and is planning on contributing to uPortal in the future to go and sign up for an account on GitHub. Once that is done please either reply here or update the table on the wiki page with your account info: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal#GitMigrationProposal-UsernameMapping For example, I'm edalquist in SVN but on GitHub I'm Eric Dalquist eric.dalqu...@gmail.com This isn't critical but if we don't map usernames when we do the switch your old commits won't be associated with your new GitHub username. -Eric On 09/29/2011 05:56 PM, Cris J Holdorph wrote: My vote after 4.0.1 is released, will be +1. Cris J H On 09/29/2011 03:48 PM, Steve Swinsburg wrote: With the svn read-only mirror and the other discussions that have taken place around governance, my vote is now a +1. cheers, Steve On 30/09/2011, at 7:45 AM, Eric Dalquist wrote: The GitHub migration vote currently stands at: Binding: 3 +1 10 0 -0 NonBinding: 2 +1 00 0 -0 This is enough to pass by the project voting standards but I wanted to bring this up one last time before scheduling the migration for additional input. The 4.0.1 release will be cut Friday the 30th and announced on Monday. If there is no objection from this discussion I'll work on planning the migration to GitHub after the announcement. One thing I'd like anyone here who contributes code to uPortal, either directly or through patches, is to take a look at this REALLY good git workflow documentation: https://github.com/diaspora/diaspora/wiki/Git-Workflow It is a great example of how get helps provide a much nicer workflow for both developers and the project/branch leads as far as committing and merging in changes. The full proposal is on the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal -Eric smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
This includes portlet contributions, or just to the core of uPortal? On Fri, Sep 30, 2011 at 3:18 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: Great, so with that support I need anyone that has committed to uPortal in the past and is planning on contributing to uPortal in the future to go and sign up for an account on GitHub. Once that is done please either reply here or update the table on the wiki page with your account info: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal#GitMigrationProposal-UsernameMapping For example, I'm edalquist in SVN but on GitHub I'm Eric Dalquist eric.dalqu...@gmail.com This isn't critical but if we don't map usernames when we do the switch your old commits won't be associated with your new GitHub username. -Eric On 09/29/2011 05:56 PM, Cris J Holdorph wrote: My vote after 4.0.1 is released, will be +1. Cris J H On 09/29/2011 03:48 PM, Steve Swinsburg wrote: With the svn read-only mirror and the other discussions that have taken place around governance, my vote is now a +1. cheers, Steve On 30/09/2011, at 7:45 AM, Eric Dalquist wrote: The GitHub migration vote currently stands at: Binding: 3 +1 1 0 0 -0 NonBinding: 2 +1 0 0 0 -0 This is enough to pass by the project voting standards but I wanted to bring this up one last time before scheduling the migration for additional input. The 4.0.1 release will be cut Friday the 30th and announced on Monday. If there is no objection from this discussion I'll work on planning the migration to GitHub after the announcement. One thing I'd like anyone here who contributes code to uPortal, either directly or through patches, is to take a look at this REALLY good git workflow documentation: https://github.com/diaspora/diaspora/wiki/Git-Workflow It is a great example of how get helps provide a much nicer workflow for both developers and the project/branch leads as far as committing and merging in changes. The full proposal is on the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal -Eric -- Bruce Tong Software Engineer Office of Information Technology Ohio University -- 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
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
This is just core uPortal. The only thing that is getting moved is https://source.jasig.org/uPortal. If individual portlet projects are interested in moving that is up to them though the same username mapping info would likely be useful. I'm going to stick the svn2git authors file in the jasig svn repo after we move uPortal's active development so that other projects can use it as well if they are interested. -Eric On 09/30/2011 02:22 PM, Bruce Tong wrote: This includes portlet contributions, or just to the core of uPortal? On Fri, Sep 30, 2011 at 3:18 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: Great, so with that support I need anyone that has committed to uPortal in the past and is planning on contributing to uPortal in the future to go and sign up for an account on GitHub. Once that is done please either reply here or update the table on the wiki page with your account info: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal#GitMigrationProposal-UsernameMapping For example, I'm edalquist in SVN but on GitHub I'm Eric Dalquist eric.dalqu...@gmail.com This isn't critical but if we don't map usernames when we do the switch your old commits won't be associated with your new GitHub username. -Eric On 09/29/2011 05:56 PM, Cris J Holdorph wrote: My vote after 4.0.1 is released, will be +1. Cris J H On 09/29/2011 03:48 PM, Steve Swinsburg wrote: With the svn read-only mirror and the other discussions that have taken place around governance, my vote is now a +1. cheers, Steve On 30/09/2011, at 7:45 AM, Eric Dalquist wrote: The GitHub migration vote currently stands at: Binding: 3 +1 10 0 -0 NonBinding: 2 +1 00 0 -0 This is enough to pass by the project voting standards but I wanted to bring this up one last time before scheduling the migration for additional input. The 4.0.1 release will be cut Friday the 30th and announced on Monday. If there is no objection from this discussion I'll work on planning the migration to GitHub after the announcement. One thing I'd like anyone here who contributes code to uPortal, either directly or through patches, is to take a look at this REALLY good git workflow documentation: https://github.com/diaspora/diaspora/wiki/Git-Workflow It is a great example of how get helps provide a much nicer workflow for both developers and the project/branch leads as far as committing and merging in changes. The full proposal is on the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal -Eric smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
The GitHub migration vote currently stands at: Binding: 3 +1 10 0 -0 NonBinding: 2 +1 00 0 -0 This is enough to pass by the project voting standards but I wanted to bring this up one last time before scheduling the migration for additional input. The 4.0.1 release will be cut Friday the 30th and announced on Monday. If there is no objection from this discussion I'll work on planning the migration to GitHub after the announcement. One thing I'd like anyone here who contributes code to uPortal, either directly or through patches, is to take a look at this REALLY good git workflow documentation: https://github.com/diaspora/diaspora/wiki/Git-Workflow It is a great example of how get helps provide a much nicer workflow for both developers and the project/branch leads as far as committing and merging in changes. The full proposal is on the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal -Eric smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
With the svn read-only mirror and the other discussions that have taken place around governance, my vote is now a +1. cheers, Steve On 30/09/2011, at 7:45 AM, Eric Dalquist wrote: The GitHub migration vote currently stands at: Binding: 3 +1 10 0 -0 NonBinding: 2 +1 00 0 -0 This is enough to pass by the project voting standards but I wanted to bring this up one last time before scheduling the migration for additional input. The 4.0.1 release will be cut Friday the 30th and announced on Monday. If there is no objection from this discussion I'll work on planning the migration to GitHub after the announcement. One thing I'd like anyone here who contributes code to uPortal, either directly or through patches, is to take a look at this REALLY good git workflow documentation: https://github.com/diaspora/diaspora/wiki/Git-Workflow It is a great example of how get helps provide a much nicer workflow for both developers and the project/branch leads as far as committing and merging in changes. The full proposal is on the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal -Eric -- 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
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
I was originally a 0 on this issue; I think the primary committers by and large won't have too much difficulty switching to git, but I shared some of the earlier concerns about deployers depending on svn. Now that this read-only mirror is possible, my vote is +1 as long as that becomes a required step in the transition. I also think we should capture in video form a number of common workflows for deploying and contributing patches using git to help those that are interested make the switch. On Wed, Sep 14, 2011 at 8:49 AM, Eric Dalquist eric.dalqu...@doit.wisc.eduwrote: I've verified that we will be able to the keep the existing https://source.jasig.org/uPortal svn data as a read-only mirror of the git repository. Existing revision numbers will not change and commits on the git side to the trunk and patches branches will automatically be reflected back to the Jasig svn repository. Hopefully this will address the needs of folks that are using svn:externals and the svn remote-merge features. -Eric On 9/11/11 9: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 1. 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 * 2. 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. 1. 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. 1. 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
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
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
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
I've verified that we will be able to the keep the existing https://source.jasig.org/uPortal svn data as a read-only mirror of the git repository. Existing revision numbers will not change and commits on the git side to the trunk and patches branches will automatically be reflected back to the Jasig svn repository. Hopefully this will address the needs of folks that are using svn:externals and the svn remote-merge features. -Eric On 9/11/11 9: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 1. 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 * 2. 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. 3. 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. 4. 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:
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
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 1. 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 * 2. 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. 3. 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. 4. 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:
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
On Wed, Aug 31, 2011 at 7:22 PM, Steve Swinsburg steve.swinsb...@gmail.com wrote: Also, as Bruce mentioned, local institutions may be using Subversion and switching this over could be a major barrier for community participation. Assuming that 3.2.x remained on SVN and 4.0+ was on GIT, I'd end up figuring out all of the differences as part of the project effort to migrate from 3.2.x to 4.0+. Going to 4.0 is already a project I'm already expecting will take extra time, so I wouldn't be concerned. If all versions of uPortal move to GIT, I might have to figure the GIT stuff out as part of my existing release schedules. I didn't forecast that time, but sometimes that's life in the big city. I can't see JASIG waiting for a hundred schools to say okay, though I do appreciate having windows of opportunity as I have more responsibilities other than the portal and it is a bummer when deadlines coincide. Wrapping GIT in my build process should be possible even though my school will stick with SVN. I'd have to remove the svn:externals part and probably replace it with some kind of script that called on some GIT tagging feature. I don't have enough disk space to make my own local uPortal SVN repository with git-svn to prop up the svn:externals feature. -- Bruce Tong Software Engineer Office of Information Technology Ohio University -- 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
[uportal-dev] [VOTE] Move uPortal source to GitHub
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
+1 On 08/31/2011 02: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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
+/- 0 I think making this change so soon after the uPortal 4.0.0 release, is a mistake. I think it would be better to let that release simmer for a while to shake out if there were any major problems. If this vote was to take place in a month, or at least 2 weeks after some university was running uPortal 4.0.0 in production, then my vote might be different. Cris J H On 08/31/2011 12: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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
+1 - Original Message - From: Jen Bourey jennifer.bou...@gmail.com To: uportal-dev@lists.ja-sig.org Sent: Wednesday, August 31, 2011 12:50:43 PM Subject: Re: [uportal-dev] [VOTE] Move uPortal source to GitHub +1 On Aug 31, 2011, at 12: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: jlich...@unicon.net 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
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
There's a command line interface, cool. Does git have anything like svn:externals? A quick search brought up a few pages that lead me to believe it might be an issue, though if a read-only SVN repository is still part of the plan, maybe that covers it. I'd have to do more research. On Wed, Aug 31, 2011 at 3:26 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: 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 -- Bruce Tong Software Engineer Office of Information Technology Ohio University -- 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
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
I'm curious as yo why the concern about the closeness to the 4.0 release? I was actually thinking that doing the switch as soon as possible after 4.0 would be better as it would give more time for developers to get used to the change before a 4.0.1 is needed. -Eric On 8/31/11 3:05 PM, Cris J Holdorph wrote: +/- 0 I think making this change so soon after the uPortal 4.0.0 release, is a mistake. I think it would be better to let that release simmer for a while to shake out if there were any major problems. If this vote was to take place in a month, or at least 2 weeks after some university was running uPortal 4.0.0 in production, then my vote might be different. Cris J H On 08/31/2011 12: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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
Call me pessimistic, but... there seem to be two givens in the world of software that concern me with this change at this time. 1) a .0 release is notoriously not perfect and is usually followed on very quickly by a .1 release shortly after to fix some glaring bug that will prevent most people from using it. 2) switching to a new source code control system is a slow process that takes a while to get over all the hurdles of process, development, migration, etc. So, there's no guarantee either one of these would be true for uportal, but... if they were. Then we could be in a situation where we're unable to produce a critically needed 4.0.1 release, because we're not completely up to development speed on git. For example, what if there is an import/export bug, you want Drew Wills to fix. He's the best guy for the job. If the code was still in svn, he probably still has a checkout of it and he can take a look at it today. But if the code only exists in git, he might not have gotten around to doing anything with git yet. Even the github svn url you can use, would still require him changing his environment. My 'vote' was 0. Basically I'm saying I won't stand in the way of it happening, but I don't believe the time is right to fully support it right now either. Cris J H On 08/31/2011 02:05 PM, Eric Dalquist wrote: I'm curious as yo why the concern about the closeness to the 4.0 release? I was actually thinking that doing the switch as soon as possible after 4.0 would be better as it would give more time for developers to get used to the change before a 4.0.1 is needed. -Eric On 8/31/11 3:05 PM, Cris J Holdorph wrote: +/- 0 I think making this change so soon after the uPortal 4.0.0 release, is a mistake. I think it would be better to let that release simmer for a while to shake out if there were any major problems. If this vote was to take place in a month, or at least 2 weeks after some university was running uPortal 4.0.0 in production, then my vote might be different. Cris J H On 08/31/2011 12: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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
Not officially voting just yet as I'd like to see this really thrashed out. Switching to a different SCM system can isolate users who don't know how to use it. Git is complex. Much more so than Subversion. It may be more powerful but that doesn't mean a lot to the average user who wants to fix something locally. Also, as Bruce mentioned, local institutions may be using Subversion and switching this over could be a major barrier for community participation. Personally, I am in favour of the move, but after uP4 is well out the door and stable enough that critical bugs don't need fixing in short timelines. Also, I'd like to see some discussion of how this will play out with the Sakai-Jasig merger. As Cris pointed out, Sakai (CLE) is a heavy user of Subversion and svn:externals, and it works really well. There may also be some broader strategy that will pan out as the merger progresses - I am sure that some areas of both Sakai and Jasig will receive attention so that they are brought in line with each other. So switching SCM now might be a bit premature. http://groups.google.com/group/jasig-sakai-collaboration regards, Steve On 01/09/2011, at 8:27 AM, Cris J Holdorph wrote: I'm currently working on a project that's doing something with Sakai. If you ever look at Sakai you'll find out they are big users of svn:externals. Anyway, we're trying to use Git and we're using a moderately complex system, in order to accomplish something that's kind of like a cross between subversion vendor drops and svn:externals. If you're interested in the details let me know, I'd be happy to discuss them with you. Unfortunately I can't type them all out here, because I don't have all the details myself, I need to talk to another team member on the project. Cris J H On 08/31/2011 01:29 PM, Bruce Tong wrote: There's a command line interface, cool. Does git have anything like svn:externals? A quick search brought up a few pages that lead me to believe it might be an issue, though if a read-only SVN repository is still part of the plan, maybe that covers it. I'd have to do more research. On Wed, Aug 31, 2011 at 3:26 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: 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: steve.swinsb...@gmail.com 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
