From: Andrea A. <and...@ge...> - 2012-01-21 10:52:46
|
Hi, the eventual move of GeoTools from svn to git is looking to me more and more like the move to java 6: something eventually unavoidable, but for which we have to pick a good timing. For the Java 6 we run a periodic discussion a few times (I think I've sent mails to check if the timing was good a few times in the past two years before we make the switch), thought it might be good to do the same for git. As far as I can see most of the developers of GeoTools are using git in some way or the other, either as a svn client++ or as a full blown version control for other projects. In the discussion we had on GeoServer several months ago it was pointed out that the major roadblock was lack of git knowledge by the typical corporate developer: http://osgeo-org.1560.n6.nabble.com/Community-modules-and-the-whole-development-process-td3821655.html#none There was also some pushback in favor of hg, but from what I can see around on the net it seems git is winning the distributed version control war hands down (probably more because of user base enthusiasm and the presence of github than raw merits, but that's another story): http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend (or see the number of people using each on ohloh, http://www.ohloh.net/p/git http://www.ohloh.net/p/mercurial, top right "I use this" icon) At the same time it seems there is little interested in that kind of people to contribute to GeoTools/GeoServer anyways. Wondering if the typical git user would be more inclined to contribute changes? Anyways, I'm not pushing, would just like a refresh of people views 9 months after the last discussion. Also wondering if we should setup a poll and invite GeoTools users to answer it to get a feel from the user community? Opinions welcomed: bring it on! Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- |
From: Justin D. <jde...@op...> - 2012-01-21 16:45:24
|
Thanks for refreshing the topic Andrea. I too agree that the move to git is eventually inevitable and coming sooner rather than later. Some random thoughts. I think it will be key to have some good docs in the developer guide about git. Nothing too crazy, but a quick little reference guide for git given within the context of geotools. Some basic commands with a list of does and dont's. I have used git for vcs on other projects and there can certainly be pitfalls and ways you can shoot yourself in the foot. One is with rebasing. I don't know about others but I love git rebasing. I really like it when I am on a branch doing a bunch of changes that show up as various commits over time, i like the ability to be able to do an update, or merge with another branch, but stick all my changes at the very end, keeping the history clean. Or interactive rebasing where you can merge two commits together, remove commits, etc... Well as many know this rewrites history in the repo, so if that branch is shared with someone else you have just screwed them for the next merge. The release guide will have to be updated, but also we will have to tweak our release process a little bit. Like how exactly does one do a release? Do I create a branch from the branch we are releasing from, do all the release work on the branch, and then merge back into master? Or do we simply keep the branch around, update README / pom etc... and then tag that branch? Things like that. This is more an issue for geoserver but there is no exact parallell for svn externals in git. Git has submodules, which are quite a different beast. The main difference is that while svn externals let you point to any place in a repository, git submodules force you to bring in an entire repository. So this will take some updating. Then there is the question of hosting. I have really only used github, which i can't say anything bad about... well except maybe that the issue tracker is a bit too limited, but getting better. I know udig uses gitorious, curious to here from them as to why they went that route. From what I can read online comparing the two it seems github has more features and is better supported. [1] http://stackoverflow.com/questions/78991/why-is-github-more-popular-than-gitorious The question of issue tracker is an interesting as well. While the github issue tracker is not nearly as fully featured as jira, would we even consider switching? One major benefit would be the integrated issue commenting with the ability to make a comment on in issue in a commit message, or even close an issue from a commit message. I am guessing this won't be enticing enough... we actually had this setup for a while in hudson and jira and i don't think it saw much use, certainly noone complained when it went away. Finally yes, I definitely think a poll would be a great idea to hear from the community on this one. - my somewhat more than $0.02 On Sat, Jan 21, 2012 at 3:52 AM, Andrea Aime <and...@ge...>wrote: > Hi, > the eventual move of GeoTools from svn to git is looking to me more and > more > like the move to java 6: something eventually unavoidable, but for which > we have to pick a good timing. > > For the Java 6 we run a periodic discussion a few times (I think I've sent > mails > to check if the timing was good a few times in the past two years before > we make the switch), thought it might be good to do the same for git. > > As far as I can see most of the developers of GeoTools are using git > in some way or the other, either as a svn client++ or as a full blown > version control for other projects. > > In the discussion we had on GeoServer several months ago it was pointed > out that the major roadblock was lack of git knowledge by the typical > corporate developer: > > http://osgeo-org.1560.n6.nabble.com/Community-modules-and-the-whole-development-process-td3821655.html#none > > There was also some pushback in favor of hg, but from what I can > see around on the net it seems git is winning the distributed version > control war hands down (probably more because of user base enthusiasm > and the presence of github than raw merits, but that's another story): > > http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend > (or see the number of people using each on ohloh, > http://www.ohloh.net/p/git > http://www.ohloh.net/p/mercurial, top right "I use this" icon) > > At the same time it seems there is little interested in that kind of people > to contribute to GeoTools/GeoServer anyways. Wondering if the > typical git user would be more inclined to contribute changes? > > Anyways, I'm not pushing, would just like a refresh of people views > 9 months after the last discussion. > > Also wondering if we should setup a poll and invite GeoTools users > to answer it to get a feel from the user community? > > Opinions welcomed: bring it on! > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
From: Andrea A. <and...@ge...> - 2012-01-21 17:45:35
|
On Sat, Jan 21, 2012 at 5:45 PM, Justin Deoliveira <jde...@op...>wrote: > Thanks for refreshing the topic Andrea. I too agree that the move to git > is eventually inevitable and coming sooner rather than later. Some random > thoughts. > > I think it will be key to have some good docs in the developer guide about > git. Nothing too crazy, but a quick little reference guide for git given > within the context of geotools. Some basic commands with a list of does and > dont's. > There is a number of basic intros and cheat-sheets around, what would be geotools specific? I guess the way we manage branches, forks, and who can commit where? > > I have used git for vcs on other projects and there can certainly be > pitfalls and ways you can shoot yourself in the foot. One is with rebasing. > I don't know about others but I love git rebasing. I really like it when I > am on a branch doing a bunch of changes that show up as various commits > over time, i like the ability to be able to do an update, or merge with > another branch, but stick all my changes at the very end, keeping the > history clean. Or interactive rebasing where you can merge two commits > together, remove commits, etc... Well as many know this rewrites history in > the repo, so if that branch is shared with someone else you have just > screwed them for the next merge. > Yep, I'm an avid user of interactive rebasing me too. First commit as one sees fit, even with stuff not compiling, while coding and (inevitably) jumping from one branch to the other to follow this and that project/customer, then cleanup with an interactive rebase to come up with something presentable to the rest of the community. Working against svn makes this somewhat easy, in fact I don't believe the usual "git pull" would keep the local history at the end, wouldn't it? > > The release guide will have to be updated, but also we will have to tweak > our release process a little bit. Like how exactly does one do a release? > Do I create a branch from the branch we are releasing from, do all the > release work on the branch, and then merge back into master? Or do we > simply keep the branch around, update README / pom etc... and then tag that > branch? Things like that. > Yep > > This is more an issue for geoserver but there is no exact parallell for > svn externals in git. Git has submodules, which are quite a different > beast. The main difference is that while svn externals let you point to any > place in a repository, git submodules force you to bring in an > entire repository. So this will take some updating. > Right. I guess most of the reason for externals in svn was to allow people with bad internet connections to download the data and documentation? However with git one has to download the whole repo, so the reason for some of the externals would cease to exist (also, the data area is not growing and internet connection speed went up significantly in the last 5 years). > > Then there is the question of hosting. I have really only used github, > which i can't say anything bad about... well except maybe that the issue > tracker is a bit too limited, but getting better. I know udig uses > gitorious, curious to here from them as to why they went that route. From > what I can read online comparing the two it seems github has more features > and is better supported. > > [1] > http://stackoverflow.com/questions/78991/why-is-github-more-popular-than-gitorious > A bit old. To be honest I never looked at gitorious but I believe uDig had a rough ride with it and eventually switched to github? The fact that one can also host private company repos and public open repos on the same platform is also a plus to me. > > The question of issue tracker is an interesting as well. While the github > issue tracker is not nearly as fully featured as jira, would we even > consider switching? One major benefit would be the integrated issue > commenting with the ability to make a comment on in issue in a commit > message, or even close an issue from a commit message. I am guessing this > won't be enticing enough... we actually had this setup for a while in > hudson and jira and i don't think it saw much use, certainly noone > complained when it went away. > Ugh, the bug tracker at github is pathetic to say the least, it's ok if you have 10 open issues, but when you have hundreds, give me jira any day :-) > > Finally yes, I definitely think a poll would be a great idea to hear from > the community on this one. > Cool, a few more +1 on the idea and I'll setup one Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- |
From: Justin D. <jde...@op...> - 2012-01-21 21:00:50
|
On Sat, Jan 21, 2012 at 10:45 AM, Andrea Aime <and...@ge...>wrote: > On Sat, Jan 21, 2012 at 5:45 PM, Justin Deoliveira <jde...@op...>wrote: > >> Thanks for refreshing the topic Andrea. I too agree that the move to git >> is eventually inevitable and coming sooner rather than later. Some random >> thoughts. >> >> I think it will be key to have some good docs in the developer guide >> about git. Nothing too crazy, but a quick little reference guide for git >> given within the context of geotools. Some basic commands with a list of >> does and dont's. >> > > There is a number of basic intros and cheat-sheets around, what would be > geotools specific? > I guess the way we manage branches, forks, and who can commit where? > Yeah, that is sort of what i had in mind... with maybe a bit of help of how to set up your local repo... with like instructions or recommendations of how to setup your forked repo, with a remote linking back to the canonical one. > > >> >> I have used git for vcs on other projects and there can certainly be >> pitfalls and ways you can shoot yourself in the foot. One is with rebasing. >> I don't know about others but I love git rebasing. I really like it when I >> am on a branch doing a bunch of changes that show up as various commits >> over time, i like the ability to be able to do an update, or merge with >> another branch, but stick all my changes at the very end, keeping the >> history clean. Or interactive rebasing where you can merge two commits >> together, remove commits, etc... Well as many know this rewrites history in >> the repo, so if that branch is shared with someone else you have just >> screwed them for the next merge. >> > > Yep, I'm an avid user of interactive rebasing me too. First commit as one > sees fit, even with stuff not compiling, while coding and (inevitably) > jumping > from one branch to the other to follow this and that project/customer, > then cleanup with an interactive rebase to come up with something > presentable > to the rest of the community. Working against svn makes this somewhat > easy, in fact I don't believe the usual "git pull" would keep the local > history > at the end, wouldn't it? > Nope, not unless you use the --rebase flag. That will basically roll back any local changed, so the fetch/merge, and then reapply your changes. A regular pull would result in the commits sorted chronologically as i understand it. > > >> >> The release guide will have to be updated, but also we will have to tweak >> our release process a little bit. Like how exactly does one do a release? >> Do I create a branch from the branch we are releasing from, do all the >> release work on the branch, and then merge back into master? Or do we >> simply keep the branch around, update README / pom etc... and then tag that >> branch? Things like that. >> > > Yep > > >> >> This is more an issue for geoserver but there is no exact parallell for >> svn externals in git. Git has submodules, which are quite a different >> beast. The main difference is that while svn externals let you point to any >> place in a repository, git submodules force you to bring in an >> entire repository. So this will take some updating. >> > > Right. I guess most of the reason for externals in svn was to allow people > with bad internet connections to download the > data and documentation? However with git one has to download the whole > repo, so the reason for some of the externals > would cease to exist (also, the data area is not growing and internet > connection speed went up significantly in the last > 5 years). > Yeah, that would solve the one external from web/app, but i think app-schema uses some externals linking to some geotools test data or something. > > >> >> Then there is the question of hosting. I have really only used github, >> which i can't say anything bad about... well except maybe that the issue >> tracker is a bit too limited, but getting better. I know udig uses >> gitorious, curious to here from them as to why they went that route. From >> what I can read online comparing the two it seems github has more features >> and is better supported. >> >> [1] >> http://stackoverflow.com/questions/78991/why-is-github-more-popular-than-gitorious >> > > A bit old. To be honest I never looked at gitorious but I believe uDig had > a rough ride with > it and eventually switched to github? > The fact that one can also host private company repos and public open > repos on the same > platform is also a plus to me. > > Yeah, and we already have the canonical repos setup there... i am thinking we are leaning towards github. > >> The question of issue tracker is an interesting as well. While the github >> issue tracker is not nearly as fully featured as jira, would we even >> consider switching? One major benefit would be the integrated issue >> commenting with the ability to make a comment on in issue in a commit >> message, or even close an issue from a commit message. I am guessing this >> won't be enticing enough... we actually had this setup for a while in >> hudson and jira and i don't think it saw much use, certainly noone >> complained when it went away. >> > > Ugh, the bug tracker at github is pathetic to say the least, it's ok if > you have 10 open issues, > but when you have hundreds, give me jira any day :-) > > >> >> Finally yes, I definitely think a poll would be a great idea to hear from >> the community on this one. >> > > Cool, a few more +1 on the idea and I'll setup one > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
From: Ben Caradoc-D. <Ben...@cs...> - 2012-01-23 01:07:29
|
Not any more: I got rid of the nasty cross-project external. GS app-schema-test now gets its test dependencies from maven artifacts, as it should. On 22/01/12 05:00, Justin Deoliveira wrote: > Yeah, that would solve the one external from web/app, but i think app-schema uses some externals linking to some geotools test data or something. -- Ben Caradoc-Davies <Ben...@cs...> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre |
From: Jody G. <jod...@gm...> - 2012-01-21 22:49:02
|
I recently cut and pasted an IRC chat on #geotools over to the geotools-administraiton list. It consisted of a couple of developers being shocked we still used subversion. - Enough said on that front; >From the uDig experience: - it is not enough to move to git -> you must move to git hub to line up with the majority of documentation people lean on when learning (and the pull request workflow) - When we schedule a move to git we need to have some experienced developers available to answer email and talk on IRC to get people through the trouble spots (thanks to everyone who helped me) - The PSC needs to expect a greater workload as there there is no longer an attitude of taking part in a project; only submitting a pull request and walking away Git vs Apache: - The OSGeo Foundation seems to have taken the recent git vs apache culture clash to heart. Basically for legal reasons the Apache foundation wants to have the ability to shut down a project source code and downloads; distributed version control does not offer that "feature" - and the Apache foundation suffering a the developer community walks away. This is related to the "submit pull request and walk away" idea expressed above. - Several OSGeo projects have already migrated over to github -- Jody Garnett On Saturday, 21 January 2012 at 8:52 PM, Andrea Aime wrote: > Hi, > the eventual move of GeoTools from svn to git is looking to me more and more > like the move to java 6: something eventually unavoidable, but for which > we have to pick a good timing. > > For the Java 6 we run a periodic discussion a few times (I think I've sent mails > to check if the timing was good a few times in the past two years before > we make the switch), thought it might be good to do the same for git. > > As far as I can see most of the developers of GeoTools are using git > in some way or the other, either as a svn client++ or as a full blown > version control for other projects. > > In the discussion we had on GeoServer several months ago it was pointed > out that the major roadblock was lack of git knowledge by the typical > corporate developer: > http://osgeo-org.1560.n6.nabble.com/Community-modules-and-the-whole-development-process-td3821655.html#none > > There was also some pushback in favor of hg, but from what I can > see around on the net it seems git is winning the distributed version > control war hands down (probably more because of user base enthusiasm > and the presence of github than raw merits, but that's another story): > http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend > (or see the number of people using each on ohloh, http://www.ohloh.net/p/git > http://www.ohloh.net/p/mercurial, top right "I use this" icon) > > At the same time it seems there is little interested in that kind of people > to contribute to GeoTools/GeoServer anyways. Wondering if the > typical git user would be more inclined to contribute changes? > > Anyways, I'm not pushing, would just like a refresh of people views > 9 months after the last discussion. > > Also wondering if we should setup a poll and invite GeoTools users > to answer it to get a feel from the user community? > > Opinions welcomed: bring it on! > > Cheers > Andrea > > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > > _______________________________________________ > Geotools-devel mailing list > Geo...@li... (mailto:Geo...@li...) > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > |
From: Andrea A. <and...@ge...> - 2012-01-22 16:56:11
|
On Sat, Jan 21, 2012 at 11:48 PM, Jody Garnett <jod...@gm...>wrote: > I recently cut and pasted an IRC chat on #geotools over to the > geotools-administraiton list. It consisted of a couple of developers being > shocked we still used subversion. > Oh, is that mailing list still in use? I don't think I'm subscribed to it anymore > > - Enough said on that front; > > From the uDig experience: > - it is not enough to move to git -> you must move to git hub to line up > with the majority of documentation people lean on when learning (and the > pull request workflow) > - When we schedule a move to git we need to have some experienced > developers available to answer email and talk on IRC to get people through > the trouble spots (thanks to everyone who helped me) > - The PSC needs to expect a greater workload as there there is no longer > an attitude of taking part in a project; only submitting a pull request and > walking away > To be blunt, what's the last time we've seen someone really interested to take part in the project, maintain a module? More often than not I see people sending us a patch, often without a test, and then walk away anyways. > Git vs Apache: > - The OSGeo Foundation seems to have taken the recent git vs apache > culture clash to heart. Basically for legal reasons the Apache foundation > wants to have the ability to shut down a project source code and downloads; > distributed version control does not offer that "feature" - and the Apache > foundation suffering a the developer community walks away. This is related > to the "submit pull request and walk away" idea expressed above. > - Several OSGeo projects have already migrated over to github > I see the Apache position. Does OSGEO have an official position too? Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- |
From: Jody G. <jod...@gm...> - 2012-01-22 23:20:20
|
> Oh, is that mailing list still in use? I don't think I'm subscribed to it anymore > > > Yep. > - The PSC needs to expect a greater workload as there there is no longer an attitude of taking part in a project; only submitting a pull request and walking away > > To be blunt, what's the last time we've seen someone really interested to take part in the project, maintain a module? > More often than not I see people sending us a patch, often without a test, and then walk away anyways. > > > We do however see people interested in starting (but perhaps not finishing) unsupported modules. > I see the Apache position. Does OSGEO have an official position too? > > > With respect to project migrating to github (or being located elsewhere) they are all for it; where a project is located has no reflection on their involvement with OSGeo. As for the apache thing they want to be very careful not to fall in the same trap (of not being where the developers are). As for pulling the code/downloads GeoTools is the best example (of when we shut off downloads when we found we were distributing ESRI jars). Other than that they have no working example; and a few projects migrating to github. I expect as long as a project shut off downloads I expect it would show the organisation acting in good faith when a lawsuit started. Jody |