Since Chris has been drumming up a lot of interest in our project, and since Ariel's joined us, it's time we expanded our community infrastructure and moved it to a more permanent place. David and I just had a meeting where we listed tasks and changes needed to provide better community support. I'm repeating that list below to get your feedback and ask the questions it raises. If there are no objections then we will move forward on these as described. * Get a separate server for the geonode.org website and to host the generic demo that will be updated from trunk. Main thing here is that we need to be able to give core community members access to the server, and have it be disentangled from the rest of OpenGeo's stuff. * Switch official repository to Github for hosting the code. We have access to http://github.com/geonode and David and I agree that the evidence has panned out that github is good for project publicity. (See for example http://tinyurl.com/yhens8c ) . To effect this transition, this will require some changes to how we do JavaScript dependency management. * Migrate the task tracking from projects.opengeo.org/CAPRA to a more generic location. We were discussing using github's project management tools, but wanted to raise the issue to the list. * Finalize mailing lists to an @geonode.org domain and with a mailing list system we can configure and archive. * Developer documentation to help people get started. * Hosting of documentation at geonoder.org/dev We've got the mandate to do work on this over the course of the next month, with David taking the lead on it. Any thoughts or ideas about these changes coming up? Thanks, -- Sebastian Benthall OpenGeo - http://opengeo.org
On 05/12/2010 03:52 PM, Sebastian Benthall wrote: > * Switch official repository to Github for hosting the code. We > have access to http://github.com/geonode and David and I agree that > the evidence has panned out that github is good for project publicity. > (See for example http://tinyurl.com/yhens8c ) . To effect this > transition, this will require some changes to how we do JavaScript > dependency management. I've been pondering this and doing a bit of research. I see about 4 different approaches to this issue. 1 - We create a script (or maybe we use something like braid <http://wiki.github.com/evilchelu/braid/>) to mimic what we are doing, just not directly in the VCS. Pros - we're still working directly off of the SVN of our dependencies, minimal change to workflow Cons - poor integration (checkout consists of "install git, install svn, install braid, git clone, braid update") 2 - We mirror all our SVN externals so we can use git submodules <http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html> to do the same thing. Pros - slightly better integration than braid on the client end (checkout consists of "install git, git clone, git submodule update --init";) Cons - maintaining git clones of svn projects, two-tier process to push changes back 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches <http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html>. Pros - even better integration than git submodule, when you checkout the project you get everything. Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and even bringing in updates is kind of a pain. 4 - We stop checking out dependencies into the source tree and use a static download to fetch them instead. This could be a simple URL fetch like we currently do with GeoNetwork/Intermap, or it could include some version metadata like Maven or easy_install use. Pros - portable if we ever switch vcs tools again? Cons - more rigid structure/setup process, upgrading the version means publishing a new artifact in the dependency repository. I am currently thinking that choice #3 in the above list is the nicest. It allows us to version *exactly* the revision of all dependencies, unlike the current system where checking out an older revision may fail (because it's still pulling in whatever's latest from svn:externals). In addition, I think we can mitigate the hassle of extracting diffs by just keeping a branch where those dependencies are always the unmodified version from upstream. (We could even make that the main/trunk/master branch that we do deployments from.) But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. -- David Winslow OpenGeo - http://opengeo.org/
So, we were a bit short-staffed last week due to the Understanding Risk conference, but I went ahead and set up the projects according to scheme #2 from my original proposals, with the exception that ExtJS is downloaded from Cachefly (ie, the same way you would download it from their web site). These are up on GitHub now: http://github.com/GeoNode/ The setup process should be pretty familiar for those coming from the old system: 1. git clone git@github.com:GeoNode/geonode.git 2. git submodule update --init 3. python bootstrap.py 4. source bin/activate 5. paver build I'll document this in a more permanent place shortly. Anyway, now that we're on git we can move to a more sandboxy model (basically, all contributors fork the project and work in their own forks, issuing pull requests when they have something suitable for 'master') or we can all push to the same github repository. I don't think we've had any issues thus far so I'd tend toward just giving everyone write access (which doesn't preclude forking or branching for particularly pervasive changes). If you'd like commit access to the repository on Github please email me with your github account name. The other thing is the transition process. I think everyone on the team is somewhat familiar with git (except Andreas?) so I had hoped we'd be able to do this with a fairly brief transition period. Unfortunately, Andreas is in the middle of a largish refactoring on SVN trunk, so I guess it makes some sense to keep the SVN repo running until he gets that committed (and he's on vacation this week.) Therefore, I propose we keep the SVN repository up until June 25 (Friday two weeks from now) but start using the git repository for new work. I'll be merging any changes made to the SVN repo to github, but not the other way, during the interim. Or we can just keep working in SVN until Andreas gets back; it's pretty easy to update the converted repository. -- David Winslow OpenGeo - http://opengeo.org/ On 05/25/2010 05:30 PM, David Winslow wrote: > On 05/12/2010 03:52 PM, Sebastian Benthall wrote: >> * Switch official repository to Github for hosting the code. We >> have access to http://github.com/geonode and David and I agree that >> the evidence has panned out that github is good for project >> publicity. (See for example http://tinyurl.com/yhens8c ) . To >> effect this transition, this will require some changes to how we do >> JavaScript dependency management. > > I've been pondering this and doing a bit of research. I see about 4 > different approaches to this issue. > > 1 - We create a script (or maybe we use something like braid > <http://wiki.github.com/evilchelu/braid/>) to mimic what we are doing, > just not > directly in the VCS. > Pros - we're still working directly off of the SVN of our > dependencies, minimal change to workflow > Cons - poor integration (checkout consists of "install git, > install svn, install braid, git clone, > braid update") > > 2 - We mirror all our SVN externals so we can use git submodules > <http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html> > to do the same thing. > Pros - slightly better integration than braid on the client end > (checkout consists of "install git, > git clone, git submodule update --init";) > Cons - maintaining git clones of svn projects, two-tier process to > push changes back > > 3 - We commit all SVN externals directly to the git repository, kind > of like svn vendor branches > <http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html>. > Pros - even better integration than git submodule, when you > checkout the project you get > everything. > Cons - it takes a bit of digging in the repository to extract > diffs to submit upstream patches, and > even bringing in updates is kind of a pain. > > 4 - We stop checking out dependencies into the source tree and use a > static download to fetch them > instead. This could be a simple URL fetch like we currently do > with GeoNetwork/Intermap, or it > could include some version metadata like Maven or easy_install use. > Pros - portable if we ever switch vcs tools again? > Cons - more rigid structure/setup process, upgrading the version > means publishing a new artifact > in the dependency repository. > > I am currently thinking that choice #3 in the above list is the > nicest. It allows us to version *exactly* the revision of all > dependencies, unlike the current system where checking out an older > revision may fail (because it's still pulling in whatever's latest > from svn:externals). In addition, I think we can mitigate the hassle > of extracting diffs by just keeping a branch where those dependencies > are always the unmodified version from upstream. (We could even make > that the main/trunk/master branch that we do deployments from.) > > But I'm open to alternatives/arguments. However, let's try and be > git-friendly by, say, Friday next week? I'm not aware of a hard > deadline but at the rate this discussion's been going we'll never get > converted. > > -- > David Winslow > OpenGeo - http://opengeo.org/
Great stuff Dave. My github user name is groldan. Cheers, Gabriel
This is great. Once we switch to git we should turn off code browsing in Trac to avoid confusion--unless there is a way to point Trac at github? That may be transitional though, since we've talk a bit about transitioning to github for project management tools. I am ambivalent on this, since the transition will involved a lot of overhead and some relearning (and will involved some changes to processes internal to OpenGeo...) but it would centralize our project web presence. What are your thoughts on this? On Mon, Jun 7, 2010 at 10:44 AM, David Winslow <dwinslow@opengeo.org> wrote: > So, we were a bit short-staffed last week due to the Understanding Risk > conference, but I went ahead and set up the projects according to scheme #2 > from my original proposals, with the exception that ExtJS is downloaded from > Cachefly (ie, the same way you would download it from their web site). > These are up on GitHub now: http://github.com/GeoNode/ > > The setup process should be pretty familiar for those coming from the old > system: > 1. git clone git@github.com:GeoNode/geonode.git > 2. git submodule update --init > 3. python bootstrap.py > 4. source bin/activate > 5. paver build > > I'll document this in a more permanent place shortly. Anyway, now that > we're on git we can move to a more sandboxy model (basically, all > contributors fork the project and work in their own forks, issuing pull > requests when they have something suitable for 'master') or we can all push > to the same github repository. I don't think we've had any issues thus far > so I'd tend toward just giving everyone write access (which doesn't preclude > forking or branching for particularly pervasive changes). If you'd like > commit access to the repository on Github please email me with your github > account name. > > The other thing is the transition process. I think everyone on the team is > somewhat familiar with git (except Andreas?) so I had hoped we'd be able to > do this with a fairly brief transition period. Unfortunately, Andreas is in > the middle of a largish refactoring on SVN trunk, so I guess it makes some > sense to keep the SVN repo running until he gets that committed (and he's on > vacation this week.) Therefore, I propose we keep the SVN repository up > until June 25 (Friday two weeks from now) but start using the git repository > for new work. I'll be merging any changes made to the SVN repo to github, > but not the other way, during the interim. > > Or we can just keep working in SVN until Andreas gets back; it's pretty > easy to update the converted repository. > > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On 05/25/2010 05:30 PM, David Winslow wrote: > > On 05/12/2010 03:52 PM, Sebastian Benthall wrote: > > * Switch official repository to Github for hosting the code. We have > access to http://github.com/geonode and David and I agree that the > evidence has panned out that github is good for project publicity. (See for > example http://tinyurl.com/yhens8c ) . To effect this transition, this > will require some changes to how we do JavaScript dependency management. > > > I've been pondering this and doing a bit of research. I see about 4 > different approaches to this issue. > > 1 - We create a script (or maybe we use something like braid<http://wiki.github.com/evilchelu/braid/>) > to mimic what we are doing, just not > directly in the VCS. > Pros - we're still working directly off of the SVN of our dependencies, > minimal change to workflow > Cons - poor integration (checkout consists of "install git, install > svn, install braid, git clone, > braid update") > > 2 - We mirror all our SVN externals so we can use git submodules<http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html>to do the same thing. > Pros - slightly better integration than braid on the client end > (checkout consists of "install git, > git clone, git submodule update --init";) > Cons - maintaining git clones of svn projects, two-tier process to push > changes back > > 3 - We commit all SVN externals directly to the git repository, kind of > like svn vendor branches<http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html> > . > Pros - even better integration than git submodule, when you checkout > the project you get > everything. > Cons - it takes a bit of digging in the repository to extract diffs to > submit upstream patches, and > even bringing in updates is kind of a pain. > > 4 - We stop checking out dependencies into the source tree and use a static > download to fetch them > instead. This could be a simple URL fetch like we currently do with > GeoNetwork/Intermap, or it > could include some version metadata like Maven or easy_install use. > Pros - portable if we ever switch vcs tools again? > Cons - more rigid structure/setup process, upgrading the version means > publishing a new artifact > in the dependency repository. > > I am currently thinking that choice #3 in the above list is the nicest. It > allows us to version *exactly* the revision of all dependencies, unlike the > current system where checking out an older revision may fail (because it's > still pulling in whatever's latest from svn:externals). In addition, I > think we can mitigate the hassle of extracting diffs by just keeping a > branch where those dependencies are always the unmodified version from > upstream. (We could even make that the main/trunk/master branch that we do > deployments from.) > > But I'm open to alternatives/arguments. However, let's try and be > git-friendly by, say, Friday next week? I'm not aware of a hard deadline > but at the rate this discussion's been going we'll never get converted. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > > -- Sebastian Benthall OpenGeo - http://opengeo.org
Right, I foolishly configured the submodules with commiter URLs to the SVN mirrors. I've updated the repository with a new submodule setup that shouldn't require a github account at all to check out. Supposedly you can use "git submodule sync" to fix up submodules in an existing repo, but this hasn't worked well for me so it may be easier to just clone a new one. -d On 06/07/2010 01:18 PM, Luke Tucker wrote: > Hey, > > It looks like I (and others?) might need to be added to some of the > other modules as well to clone from the 'central' geonode git repo > with the steps provided... I'm getting permission denied checking out > PrintPreview (for example) when doing the submodule init step. > > - Luke >
> > The other thing is the transition process. I think everyone on the team is > somewhat familiar with git (except Andreas?) so I had hoped we'd be able to > do this with a fairly brief transition period. Unfortunately, Andreas is in > the middle of a largish refactoring on SVN trunk, so I guess it makes some > sense to keep the SVN repo running until he gets that committed (and he's on > vacation this week.) Therefore, I propose we keep the SVN repository up > until June 25 (Friday two weeks from now) but start using the git repository > for new work. I'll be merging any changes made to the SVN repo to github, > but not the other way, during the interim. > +1 on this transition plan. > On 05/25/2010 05:30 PM, David Winslow wrote: > > On 05/12/2010 03:52 PM, Sebastian Benthall wrote: > > * Switch official repository to Github for hosting the code. We have > access to http://github.com/geonode and David and I agree that the > evidence has panned out that github is good for project publicity. (See for > example http://tinyurl.com/yhens8c ) . To effect this transition, this > will require some changes to how we do JavaScript dependency management. > > > I've been pondering this and doing a bit of research. I see about 4 > different approaches to this issue. > > 1 - We create a script (or maybe we use something like braid<http://wiki.github.com/evilchelu/braid/>) > to mimic what we are doing, just not > directly in the VCS. > Pros - we're still working directly off of the SVN of our dependencies, > minimal change to workflow > Cons - poor integration (checkout consists of "install git, install > svn, install braid, git clone, > braid update") > > 2 - We mirror all our SVN externals so we can use git submodules<http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html>to do the same thing. > Pros - slightly better integration than braid on the client end > (checkout consists of "install git, > git clone, git submodule update --init";) > Cons - maintaining git clones of svn projects, two-tier process to push > changes back > > 3 - We commit all SVN externals directly to the git repository, kind of > like svn vendor branches<http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html> > . > Pros - even better integration than git submodule, when you checkout > the project you get > everything. > Cons - it takes a bit of digging in the repository to extract diffs to > submit upstream patches, and > even bringing in updates is kind of a pain. > > 4 - We stop checking out dependencies into the source tree and use a static > download to fetch them > instead. This could be a simple URL fetch like we currently do with > GeoNetwork/Intermap, or it > could include some version metadata like Maven or easy_install use. > Pros - portable if we ever switch vcs tools again? > Cons - more rigid structure/setup process, upgrading the version means > publishing a new artifact > in the dependency repository. > > I am currently thinking that choice #3 in the above list is the nicest. It > allows us to version *exactly* the revision of all dependencies, unlike the > current system where checking out an older revision may fail (because it's > still pulling in whatever's latest from svn:externals). In addition, I > think we can mitigate the hassle of extracting diffs by just keeping a > branch where those dependencies are always the unmodified version from > upstream. (We could even make that the main/trunk/master branch that we do > deployments from.) > > But I'm open to alternatives/arguments. However, let's try and be > git-friendly by, say, Friday next week? I'm not aware of a hard deadline > but at the rate this discussion's been going we'll never get converted. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > > -- Sebastian Benthall OpenGeo - http://opengeo.org
Hi, sounds great to me! It's not that I am totally unfamiliar with git, but waiting until the refactoring is committed makes things definitely easier. Thanks for the patience everyone. -Andreas. On Jun 7, 2010, at 23:09 , Sebastian Benthall wrote: > The other thing is the transition process. I think everyone on the team is somewhat familiar with git (except Andreas?) so I had hoped we'd be able to do this with a fairly brief transition period. Unfortunately, Andreas is in the middle of a largish refactoring on SVN trunk, so I guess it makes some sense to keep the SVN repo running until he gets that committed (and he's on vacation this week.) Therefore, I propose we keep the SVN repository up until June 25 (Friday two weeks from now) but start using the git repository for new work. I'll be merging any changes made to the SVN repo to github, but not the other way, during the interim. > > +1 on this transition plan. > > > > On 05/25/2010 05:30 PM, David Winslow wrote: >> On 05/12/2010 03:52 PM, Sebastian Benthall wrote: >>> * Switch official repository to Github for hosting the code. We have access to http://github.com/geonode and David and I agree that the evidence has panned out that github is good for project publicity. (See for example http://tinyurl.com/yhens8c ) . To effect this transition, this will require some changes to how we do JavaScript dependency management. >> >> I've been pondering this and doing a bit of research. I see about 4 different approaches to this issue. >> >> 1 - We create a script (or maybe we use something like braid) to mimic what we are doing, just not >> directly in the VCS. >> Pros - we're still working directly off of the SVN of our dependencies, minimal change to workflow >> Cons - poor integration (checkout consists of "install git, install svn, install braid, git clone, >> braid update") >> >> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >> git clone, git submodule update --init";) >> Cons - maintaining git clones of svn projects, two-tier process to push changes back >> >> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >> Pros - even better integration than git submodule, when you checkout the project you get >> everything. >> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >> even bringing in updates is kind of a pain. >> >> 4 - We stop checking out dependencies into the source tree and use a static download to fetch them >> instead. This could be a simple URL fetch like we currently do with GeoNetwork/Intermap, or it >> could include some version metadata like Maven or easy_install use. >> Pros - portable if we ever switch vcs tools again? >> Cons - more rigid structure/setup process, upgrading the version means publishing a new artifact >> in the dependency repository. >> >> I am currently thinking that choice #3 in the above list is the nicest. It allows us to version *exactly* the revision of all dependencies, unlike the current system where checking out an older revision may fail (because it's still pulling in whatever's latest from svn:externals). In addition, I think we can mitigate the hassle of extracting diffs by just keeping a branch where those dependencies are always the unmodified version from upstream. (We could even make that the main/trunk/master branch that we do deployments from.) >> >> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >> >> -- >> David Winslow >> OpenGeo - http://opengeo.org/ > > > > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
Update on this: Please proceed with the git migration without waiting for my commits! It is unlikely that I will be able to finish the refactoring this week. I am running out of time, working myself through the mail and list backlog and unforeseen tasks after my vacation. It is also unlikely that I will be able to finish it next week and the week after, because I will be in Zürich for 3 days next week, have to prepare my AGIT conference presentation and workshop, and attend the AGIT conference with booth duty from July 6-9. So a realistic date for finishing the refactoring will be around July 15. Sorry for that - I have not managed yet to have myself cloned :-). -Andreas. On Jun 22, 2010, at 13:00 , Andreas Hocevar wrote: > Hi, > > sounds great to me! It's not that I am totally unfamiliar with git, but waiting until the refactoring is committed makes things definitely easier. > > Thanks for the patience everyone. > > -Andreas. > > On Jun 7, 2010, at 23:09 , Sebastian Benthall wrote: > >> The other thing is the transition process. I think everyone on the team is somewhat familiar with git (except Andreas?) so I had hoped we'd be able to do this with a fairly brief transition period. Unfortunately, Andreas is in the middle of a largish refactoring on SVN trunk, so I guess it makes some sense to keep the SVN repo running until he gets that committed (and he's on vacation this week.) Therefore, I propose we keep the SVN repository up until June 25 (Friday two weeks from now) but start using the git repository for new work. I'll be merging any changes made to the SVN repo to github, but not the other way, during the interim. >> >> +1 on this transition plan. >> >> >> >> On 05/25/2010 05:30 PM, David Winslow wrote: >>> On 05/12/2010 03:52 PM, Sebastian Benthall wrote: >>>> * Switch official repository to Github for hosting the code. We have access to http://github.com/geonode and David and I agree that the evidence has panned out that github is good for project publicity. (See for example http://tinyurl.com/yhens8c ) . To effect this transition, this will require some changes to how we do JavaScript dependency management. >>> >>> I've been pondering this and doing a bit of research. I see about 4 different approaches to this issue. >>> >>> 1 - We create a script (or maybe we use something like braid) to mimic what we are doing, just not >>> directly in the VCS. >>> Pros - we're still working directly off of the SVN of our dependencies, minimal change to workflow >>> Cons - poor integration (checkout consists of "install git, install svn, install braid, git clone, >>> braid update") >>> >>> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >>> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >>> git clone, git submodule update --init";) >>> Cons - maintaining git clones of svn projects, two-tier process to push changes back >>> >>> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >>> Pros - even better integration than git submodule, when you checkout the project you get >>> everything. >>> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >>> even bringing in updates is kind of a pain. >>> >>> 4 - We stop checking out dependencies into the source tree and use a static download to fetch them >>> instead. This could be a simple URL fetch like we currently do with GeoNetwork/Intermap, or it >>> could include some version metadata like Maven or easy_install use. >>> Pros - portable if we ever switch vcs tools again? >>> Cons - more rigid structure/setup process, upgrading the version means publishing a new artifact >>> in the dependency repository. >>> >>> I am currently thinking that choice #3 in the above list is the nicest. It allows us to version *exactly* the revision of all dependencies, unlike the current system where checking out an older revision may fail (because it's still pulling in whatever's latest from svn:externals). In addition, I think we can mitigate the hassle of extracting diffs by just keeping a branch where those dependencies are always the unmodified version from upstream. (We could even make that the main/trunk/master branch that we do deployments from.) >>> >>> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >>> >>> -- >>> David Winslow >>> OpenGeo - http://opengeo.org/ >> >> >> >> >> -- >> Sebastian Benthall >> OpenGeo - http://opengeo.org >> > > -- > Andreas Hocevar > OpenGeo - http://opengeo.org/ > Expert service straight from the developers. > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
Okay. Luke, Ariel, and I have been working off the github repository for a couple of weeks now, and I can pull in SVN commits with relatively little pain. I don't *think* you will have any serious conflicts, since the modifications to the client media are pretty small (I think some CSS work is all, maybe some adjustments to the search page JS). However, if you are more comfortable with SVN you may as well use that for your refactoring, once it's in SVN I can migrate it and then kill off the SVN repo. Other than that, I think we are fully migrated. -- David Winslow OpenGeo - http://opengeo.org/ On 06/22/2010 11:43 AM, Andreas Hocevar wrote: > Update on this: > > Please proceed with the git migration without waiting for my commits! > > It is unlikely that I will be able to finish the refactoring this week. I am running out of time, working myself through the mail and list backlog and unforeseen tasks after my vacation. It is also unlikely that I will be able to finish it next week and the week after, because I will be in Zürich for 3 days next week, have to prepare my AGIT conference presentation and workshop, and attend the AGIT conference with booth duty from July 6-9. > > So a realistic date for finishing the refactoring will be around July 15. > > Sorry for that - I have not managed yet to have myself cloned :-). > > -Andreas. > > On Jun 22, 2010, at 13:00 , Andreas Hocevar wrote: > > >> Hi, >> >> sounds great to me! It's not that I am totally unfamiliar with git, but waiting until the refactoring is committed makes things definitely easier. >> >> Thanks for the patience everyone. >> >> -Andreas. >> >> On Jun 7, 2010, at 23:09 , Sebastian Benthall wrote: >> >> >>> The other thing is the transition process. I think everyone on the team is somewhat familiar with git (except Andreas?) so I had hoped we'd be able to do this with a fairly brief transition period. Unfortunately, Andreas is in the middle of a largish refactoring on SVN trunk, so I guess it makes some sense to keep the SVN repo running until he gets that committed (and he's on vacation this week.) Therefore, I propose we keep the SVN repository up until June 25 (Friday two weeks from now) but start using the git repository for new work. I'll be merging any changes made to the SVN repo to github, but not the other way, during the interim. >>> >>> +1 on this transition plan. >>> >>> >>> >>> On 05/25/2010 05:30 PM, David Winslow wrote: >>> >>>> On 05/12/2010 03:52 PM, Sebastian Benthall wrote: >>>> >>>>> * Switch official repository to Github for hosting the code. We have access to http://github.com/geonode and David and I agree that the evidence has panned out that github is good for project publicity. (See for example http://tinyurl.com/yhens8c ) . To effect this transition, this will require some changes to how we do JavaScript dependency management. >>>>> >>>> I've been pondering this and doing a bit of research. I see about 4 different approaches to this issue. >>>> >>>> 1 - We create a script (or maybe we use something like braid) to mimic what we are doing, just not >>>> directly in the VCS. >>>> Pros - we're still working directly off of the SVN of our dependencies, minimal change to workflow >>>> Cons - poor integration (checkout consists of "install git, install svn, install braid, git clone, >>>> braid update") >>>> >>>> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >>>> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >>>> git clone, git submodule update --init";) >>>> Cons - maintaining git clones of svn projects, two-tier process to push changes back >>>> >>>> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >>>> Pros - even better integration than git submodule, when you checkout the project you get >>>> everything. >>>> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >>>> even bringing in updates is kind of a pain. >>>> >>>> 4 - We stop checking out dependencies into the source tree and use a static download to fetch them >>>> instead. This could be a simple URL fetch like we currently do with GeoNetwork/Intermap, or it >>>> could include some version metadata like Maven or easy_install use. >>>> Pros - portable if we ever switch vcs tools again? >>>> Cons - more rigid structure/setup process, upgrading the version means publishing a new artifact >>>> in the dependency repository. >>>> >>>> I am currently thinking that choice #3 in the above list is the nicest. It allows us to version *exactly* the revision of all dependencies, unlike the current system where checking out an older revision may fail (because it's still pulling in whatever's latest from svn:externals). In addition, I think we can mitigate the hassle of extracting diffs by just keeping a branch where those dependencies are always the unmodified version from upstream. (We could even make that the main/trunk/master branch that we do deployments from.) >>>> >>>> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >>>> >>>> -- >>>> David Winslow >>>> OpenGeo - http://opengeo.org/ >>>> >>> >>> >>> >>> -- >>> Sebastian Benthall >>> OpenGeo - http://opengeo.org >>> >>> >> -- >> Andreas Hocevar >> OpenGeo - http://opengeo.org/ >> Expert service straight from the developers. >> >> >
Thanks for pushing this up in the queue David. > 2 - We mirror all our SVN externals so we can use git submodules<http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html>to do the same thing. > Pros - slightly better integration than braid on the client end > (checkout consists of "install git, > git clone, git submodule update --init";) > Cons - maintaining git clones of svn projects, two-tier process to push > changes back > I like this option a lot, we are using outside dependencies and the submodule step makes this crystal clear. From my conversation with David on IRC, the projects are the following: { geoext (we follow trunk) openlayers (we follow trunk) geoserver ( we modify ) geonetwork (we modify) ext (we follow trunk) gsconfig.py (we follow trunk) } The idea would be to setup git forks for those repos under the geonode git account, like this: github.com/geonode/geoext github.com/geonode/openlayers github.com/geonode/geoserver github.com/geonode/geonetwork github.com/geonode/ext github.com/geonode/gsconfig.py And put git submodules in this main repo: github.com/geonode/geonode If anybody does not like the fact that we depend on Github, we always have the option to setup: git.geonode.org 3 - We commit all SVN externals directly to the git repository, kind of > like svn vendor branches<http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html> > . > Pros - even better integration than git submodule, when you checkout > the project you get > everything. > Cons - it takes a bit of digging in the repository to extract diffs to > submit upstream patches, and > even bringing in updates is kind of a pain. > It is true this option may be the simplest for new users but I don't like the fact that patches are against "Geonode's version of X project" instead of the actual project. "Explicit is better than implicit", so #2 is still my favorite. > But I'm open to alternatives/arguments. However, let's try and be > git-friendly by, say, Friday next week? I'm not aware of a hard deadline > but at the rate this discussion's been going we'll never get converted. > +1 The sooner the better. Ariel
Just a note: we don't actually modify code in GeoServer and GeoNetwork, we simply pull in pre-built artifacts (from OpenGeo's Maven repository for GeoServer, and from an ad-hoc HTTP server for GeoNetwork) and add a couple of extensions to each. We could (should?) avoid cloning these into git. -- David Winslow OpenGeo - http://opengeo.org/ On 05/25/2010 06:49 PM, Ariel Nunez wrote: > Thanks for pushing this up in the queue David. > > 2 - We mirror all our SVN externals so we can use git submodules > <http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html> > to do the same thing. > Pros - slightly better integration than braid on the client > end (checkout consists of "install git, > git clone, git submodule update --init";) > Cons - maintaining git clones of svn projects, two-tier > process to push changes back > > I like this option a lot, we are using outside dependencies and the > submodule step makes this crystal clear. > > From my conversation with David on IRC, the projects are the following: > { > geoext (we follow trunk) > openlayers (we follow trunk) > geoserver ( we modify ) > geonetwork (we modify) > ext (we follow trunk) > gsconfig.py (we follow trunk) > } > > The idea would be to setup git forks for those repos under the geonode > git account, like this: > github.com/geonode/geoext <http://github.com/geonode/geoext> > github.com/geonode/openlayers <http://github.com/geonode/openlayers> > github.com/geonode/geoserver <http://github.com/geonode/geoserver> > github.com/geonode/geonetwork <http://github.com/geonode/geonetwork> > github.com/geonode/ext <http://github.com/geonode/ext> > github.com/geonode/gsconfig.py <http://github.com/geonode/gsconfig.py> > > And put git submodules in this main repo: > github.com/geonode/geonode <http://github.com/geonode/geonode> > > If anybody does not like the fact that we depend on Github, we always > have the option to setup: > git.geonode.org <http://git.geonode.org> > > 3 - We commit all SVN externals directly to the git repository, > kind of like svn vendor branches > <http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html>. > Pros - even better integration than git submodule, when you > checkout the project you get > everything. > Cons - it takes a bit of digging in the repository to extract > diffs to submit upstream patches, and > even bringing in updates is kind of a pain. > > It is true this option may be the simplest for new users but I don't > like the fact that patches are against "Geonode's version of X > project" instead of the actual project. "Explicit is better than > implicit", so #2 is still my favorite. > > But I'm open to alternatives/arguments. However, let's try and be > git-friendly by, say, Friday next week? I'm not aware of a hard > deadline but at the rate this discussion's been going we'll never > get converted. > > > +1 The sooner the better. > > Ariel
Another thought related to this: how hard would it be to build Maven artifacts for OpenLayers, GeoExt and gxp? Then we would not need any svn:externals at all (at least for the javascript stuff). Ah yes, and sorry if this sounds stupid. I neither have much experience with Maven nor with git at this point. Regards, Andreas. On May 26, 2010, at 17:15 , David Winslow wrote: > Just a note: we don't actually modify code in GeoServer and GeoNetwork, we simply pull in pre-built artifacts (from OpenGeo's Maven repository for GeoServer, and from an ad-hoc HTTP server for GeoNetwork) and add a couple of extensions to each. We could (should?) avoid cloning these into git. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On 05/25/2010 06:49 PM, Ariel Nunez wrote: >> Thanks for pushing this up in the queue David. >> >> >> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >> git clone, git submodule update --init";) >> Cons - maintaining git clones of svn projects, two-tier process to push changes back >> >> I like this option a lot, we are using outside dependencies and the submodule step makes this crystal clear. >> >> From my conversation with David on IRC, the projects are the following: >> { >> geoext (we follow trunk) >> openlayers (we follow trunk) >> geoserver ( we modify ) >> geonetwork (we modify) >> ext (we follow trunk) >> gsconfig.py (we follow trunk) >> } >> >> The idea would be to setup git forks for those repos under the geonode git account, like this: >> github.com/geonode/geoext >> github.com/geonode/openlayers >> github.com/geonode/geoserver >> github.com/geonode/geonetwork >> github.com/geonode/ext >> github.com/geonode/gsconfig.py >> >> And put git submodules in this main repo: >> github.com/geonode/geonode >> >> If anybody does not like the fact that we depend on Github, we always have the option to setup: >> git.geonode.org >> >> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >> Pros - even better integration than git submodule, when you checkout the project you get >> everything. >> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >> even bringing in updates is kind of a pain. >> >> It is true this option may be the simplest for new users but I don't like the fact that patches are against "Geonode's version of X project" instead of the actual project. "Explicit is better than implicit", so #2 is still my favorite. >> >> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >> >> +1 The sooner the better. >> >> Ariel > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
Not that hard; Maven handles artifacts of type ZIP just fine, and there's a one-line command to publish an artifact to a repo even if the project that published it isn't Maven-ized. It would be a bit more complicated to redo the build for the geonode client stuff in terms of Maven (needed to at least fetch those dependencies) but still pretty doable. However, this means we would want to set up nightly deployments or something if we intend to keep relying on trunk features. I don't see that as a drawback really, but it is worth mentioning. -- David Winslow OpenGeo - http://opengeo.org/ On 05/26/2010 11:25 AM, Andreas Hocevar wrote: > Another thought related to this: how hard would it be to build Maven artifacts for OpenLayers, GeoExt and gxp? Then we would not need any svn:externals at all (at least for the javascript stuff). > > Ah yes, and sorry if this sounds stupid. I neither have much experience with Maven nor with git at this point. > > Regards, > Andreas. > > On May 26, 2010, at 17:15 , David Winslow wrote: > > >> Just a note: we don't actually modify code in GeoServer and GeoNetwork, we simply pull in pre-built artifacts (from OpenGeo's Maven repository for GeoServer, and from an ad-hoc HTTP server for GeoNetwork) and add a couple of extensions to each. We could (should?) avoid cloning these into git. >> >> -- >> David Winslow >> OpenGeo - http://opengeo.org/ >> >> On 05/25/2010 06:49 PM, Ariel Nunez wrote: >> >>> Thanks for pushing this up in the queue David. >>> >>> >>> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >>> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >>> git clone, git submodule update --init";) >>> Cons - maintaining git clones of svn projects, two-tier process to push changes back >>> >>> I like this option a lot, we are using outside dependencies and the submodule step makes this crystal clear. >>> >>> From my conversation with David on IRC, the projects are the following: >>> { >>> geoext (we follow trunk) >>> openlayers (we follow trunk) >>> geoserver ( we modify ) >>> geonetwork (we modify) >>> ext (we follow trunk) >>> gsconfig.py (we follow trunk) >>> } >>> >>> The idea would be to setup git forks for those repos under the geonode git account, like this: >>> github.com/geonode/geoext >>> github.com/geonode/openlayers >>> github.com/geonode/geoserver >>> github.com/geonode/geonetwork >>> github.com/geonode/ext >>> github.com/geonode/gsconfig.py >>> >>> And put git submodules in this main repo: >>> github.com/geonode/geonode >>> >>> If anybody does not like the fact that we depend on Github, we always have the option to setup: >>> git.geonode.org >>> >>> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >>> Pros - even better integration than git submodule, when you checkout the project you get >>> everything. >>> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >>> even bringing in updates is kind of a pain. >>> >>> It is true this option may be the simplest for new users but I don't like the fact that patches are against "Geonode's version of X project" instead of the actual project. "Explicit is better than implicit", so #2 is still my favorite. >>> >>> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >>> >>> +1 The sooner the better. >>> >>> Ariel >>> >> >
On 5/26/10 8:32 AM, David Winslow wrote: > Not that hard; Maven handles artifacts of type ZIP just fine, and > there's a one-line command to publish an artifact to a repo even if the > project that published it isn't Maven-ized. It would be a bit more > complicated to redo the build for the geonode client stuff in terms of > Maven (needed to at least fetch those dependencies) but still pretty > doable. However, this means we would want to set up nightly deployments > or something if we intend to keep relying on trunk features. I don't > see that as a drawback really, but it is worth mentioning. > Though it will likely lead to a couple more headaches when someone else breaks the underlying builds I think I see it as a positive. Should help the stability of the underlying projects and also identify changes that may affect GeoNode much earlier. > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On 05/26/2010 11:25 AM, Andreas Hocevar wrote: >> Another thought related to this: how hard would it be to build Maven artifacts for OpenLayers, GeoExt and gxp? Then we would not need any svn:externals at all (at least for the javascript stuff). >> >> Ah yes, and sorry if this sounds stupid. I neither have much experience with Maven nor with git at this point. >> >> Regards, >> Andreas. >> >> On May 26, 2010, at 17:15 , David Winslow wrote: >> >> >>> Just a note: we don't actually modify code in GeoServer and GeoNetwork, we simply pull in pre-built artifacts (from OpenGeo's Maven repository for GeoServer, and from an ad-hoc HTTP server for GeoNetwork) and add a couple of extensions to each. We could (should?) avoid cloning these into git. >>> >>> -- >>> David Winslow >>> OpenGeo - http://opengeo.org/ >>> >>> On 05/25/2010 06:49 PM, Ariel Nunez wrote: >>> >>>> Thanks for pushing this up in the queue David. >>>> >>>> >>>> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >>>> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >>>> git clone, git submodule update --init";) >>>> Cons - maintaining git clones of svn projects, two-tier process to push changes back >>>> >>>> I like this option a lot, we are using outside dependencies and the submodule step makes this crystal clear. >>>> >>>> From my conversation with David on IRC, the projects are the following: >>>> { >>>> geoext (we follow trunk) >>>> openlayers (we follow trunk) >>>> geoserver ( we modify ) >>>> geonetwork (we modify) >>>> ext (we follow trunk) >>>> gsconfig.py (we follow trunk) >>>> } >>>> >>>> The idea would be to setup git forks for those repos under the geonode git account, like this: >>>> github.com/geonode/geoext >>>> github.com/geonode/openlayers >>>> github.com/geonode/geoserver >>>> github.com/geonode/geonetwork >>>> github.com/geonode/ext >>>> github.com/geonode/gsconfig.py >>>> >>>> And put git submodules in this main repo: >>>> github.com/geonode/geonode >>>> >>>> If anybody does not like the fact that we depend on Github, we always have the option to setup: >>>> git.geonode.org >>>> >>>> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >>>> Pros - even better integration than git submodule, when you checkout the project you get >>>> everything. >>>> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >>>> even bringing in updates is kind of a pain. >>>> >>>> It is true this option may be the simplest for new users but I don't like the fact that patches are against "Geonode's version of X project" instead of the actual project. "Explicit is better than implicit", so #2 is still my favorite. >>>> >>>> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >>>> >>>> +1 The sooner the better. >>>> >>>> Ariel >>>> >>> >> >
Hi, I wonder how ccnmtl do their OpenLayers trunk mirror on GitHub: http://github.com/ccnmtl/openlayers - this is always up to date with trunk. If we could mirror the other projects in a similar way, I guess that would be the way to go (easier than Maven, and better integrated). David, is this what you meant with option 2? See some more comments inline. On May 26, 2010, at 00:49 , Ariel Nunez wrote: > Thanks for pushing this up in the queue David. > > > 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. > Pros - slightly better integration than braid on the client end (checkout consists of "install git, > git clone, git submodule update --init";) > Cons - maintaining git clones of svn projects, two-tier process to push changes back > > I like this option a lot, we are using outside dependencies and the submodule step makes this crystal clear. > > From my conversation with David on IRC, the projects are the following: > { > geoext (we follow trunk) We modify - at least we create patches that we rely on. > openlayers (we follow trunk) We modify, the same way as with geoext. > geoserver ( we modify ) > geonetwork (we modify) > ext (we follow trunk) We use releases, mirrored on the geoext svn. It would be better to include the official release (to be downloaded and unpacked by the build tool) and not use git for ext. One caveat though: we are only allowed to do this if the GeoNode license is compatible (GPL 3 or similar). > gsconfig.py (we follow trunk) You forgot one: gxp (we modify) Regards, Andreas. > } > > The idea would be to setup git forks for those repos under the geonode git account, like this: > github.com/geonode/geoext > github.com/geonode/openlayers > github.com/geonode/geoserver > github.com/geonode/geonetwork > github.com/geonode/ext > github.com/geonode/gsconfig.py > > And put git submodules in this main repo: > github.com/geonode/geonode > > If anybody does not like the fact that we depend on Github, we always have the option to setup: > git.geonode.org > > 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. > Pros - even better integration than git submodule, when you checkout the project you get > everything. > Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and > even bringing in updates is kind of a pain. > > It is true this option may be the simplest for new users but I don't like the fact that patches are against "Geonode's version of X project" instead of the actual project. "Explicit is better than implicit", so #2 is still my favorite. > > But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. > > +1 The sooner the better. > > Ariel -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
I started to write an email about this but I decided it was too long. Cliff's notes version instead: * I have the geonode client build working based on Maven artifacts already (development mode isn't there yet though) * git-svn makes it really easy to keep a git repository synced to an upstream SVN repository. There are some restrictions if you want to be able to push back. * The distinction between modifiable and non-modifiable externals strikes me as not that important. We don't commit to GeoExt and OpenLayers without exporting patches and going through extensive community review anyway, so not being able to commit directly from a GeoNode checkout doesn't seem like it would be a huge change in workflow. * Working things out with ExtJS seems confusing. Why's it okay to use an SVN mirror of it, but not a git one? Maybe we could host just Ext as a Maven thing and leave the rest working like it does now. -- David Winslow OpenGeo - http://opengeo.org/ On 05/27/2010 07:50 AM, Andreas Hocevar wrote: > Hi, > > I wonder how ccnmtl do their OpenLayers trunk mirror on GitHub: http://github.com/ccnmtl/openlayers - this is always up to date with trunk. > > If we could mirror the other projects in a similar way, I guess that would be the way to go (easier than Maven, and better integrated). David, is this what you meant with option 2? > > See some more comments inline. > > On May 26, 2010, at 00:49 , Ariel Nunez wrote: > > >> Thanks for pushing this up in the queue David. >> >> >> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >> git clone, git submodule update --init";) >> Cons - maintaining git clones of svn projects, two-tier process to push changes back >> >> I like this option a lot, we are using outside dependencies and the submodule step makes this crystal clear. >> >> From my conversation with David on IRC, the projects are the following: >> { >> geoext (we follow trunk) >> > We modify - at least we create patches that we rely on. > > >> openlayers (we follow trunk) >> > We modify, the same way as with geoext. > > >> geoserver ( we modify ) >> geonetwork (we modify) >> ext (we follow trunk) >> > We use releases, mirrored on the geoext svn. It would be better to include the official release (to be downloaded and unpacked by the build tool) and not use git for ext. One caveat though: we are only allowed to do this if the GeoNode license is compatible (GPL 3 or similar). > > >> gsconfig.py (we follow trunk) >> > You forgot one: > gxp (we modify) > > Regards, > Andreas. > > >> } >> >> The idea would be to setup git forks for those repos under the geonode git account, like this: >> github.com/geonode/geoext >> github.com/geonode/openlayers >> github.com/geonode/geoserver >> github.com/geonode/geonetwork >> github.com/geonode/ext >> github.com/geonode/gsconfig.py >> >> And put git submodules in this main repo: >> github.com/geonode/geonode >> >> If anybody does not like the fact that we depend on Github, we always have the option to setup: >> git.geonode.org >> >> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >> Pros - even better integration than git submodule, when you checkout the project you get >> everything. >> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >> even bringing in updates is kind of a pain. >> >> It is true this option may be the simplest for new users but I don't like the fact that patches are against "Geonode's version of X project" instead of the actual project. "Explicit is better than implicit", so #2 is still my favorite. >> >> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >> >> +1 The sooner the better. >> >> Ariel >> >
On May 27, 2010, at 22:32 , David Winslow wrote: > I started to write an email about this but I decided it was too long. > Cliff's notes version instead: > > * I have the geonode client build working based on Maven artifacts > already (development mode isn't there yet though) Great! > * git-svn makes it really easy to keep a git repository synced to an > upstream SVN repository. There are some restrictions if you want to be > able to push back. > * The distinction between modifiable and non-modifiable externals > strikes me as not that important. We don't commit to GeoExt and > OpenLayers without exporting patches and going through extensive > community review anyway, so not being able to commit directly from a > GeoNode checkout doesn't seem like it would be a huge change in workflow. 100% agreed. > * Working things out with ExtJS seems confusing. Why's it okay to use > an SVN mirror of it, but not a git one? Our SVN mirror is approved by the Ext JS team, as long as we only use it for GeoExt development. The reason why we use it now in GeoNode is a more complicated story: We used to link to the officially hosted Ext JS version and had no local copy of it. But things changed when we switched to Ext 3.2: Tim created a temporary svn mirror in the gxp repo, which we used for the transition to Ext 3.2. I included it because we relied on it. When Ext 3.2 was released, I changed the externals source to the one in the geoext repo, instead of switching back to the hosted version or, even better, including a download of the official release in the build process. > Maybe we could host just Ext as > a Maven thing and leave the rest working like it does now. We could do that, but we should ask the Ext JS team for approval. The other option that I had in mind would be to download an official release as part of the build process - in a similar way as we currently do with the gs-data dir. -Andreas. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On 05/27/2010 07:50 AM, Andreas Hocevar wrote: >> Hi, >> >> I wonder how ccnmtl do their OpenLayers trunk mirror on GitHub: http://github.com/ccnmtl/openlayers - this is always up to date with trunk. >> >> If we could mirror the other projects in a similar way, I guess that would be the way to go (easier than Maven, and better integrated). David, is this what you meant with option 2? >> >> See some more comments inline. >> >> On May 26, 2010, at 00:49 , Ariel Nunez wrote: >> >> >>> Thanks for pushing this up in the queue David. >>> >>> >>> 2 - We mirror all our SVN externals so we can use git submodules to do the same thing. >>> Pros - slightly better integration than braid on the client end (checkout consists of "install git, >>> git clone, git submodule update --init";) >>> Cons - maintaining git clones of svn projects, two-tier process to push changes back >>> >>> I like this option a lot, we are using outside dependencies and the submodule step makes this crystal clear. >>> >>> From my conversation with David on IRC, the projects are the following: >>> { >>> geoext (we follow trunk) >>> >> We modify - at least we create patches that we rely on. >> >> >>> openlayers (we follow trunk) >>> >> We modify, the same way as with geoext. >> >> >>> geoserver ( we modify ) >>> geonetwork (we modify) >>> ext (we follow trunk) >>> >> We use releases, mirrored on the geoext svn. It would be better to include the official release (to be downloaded and unpacked by the build tool) and not use git for ext. One caveat though: we are only allowed to do this if the GeoNode license is compatible (GPL 3 or similar). >> >> >>> gsconfig.py (we follow trunk) >>> >> You forgot one: >> gxp (we modify) >> >> Regards, >> Andreas. >> >> >>> } >>> >>> The idea would be to setup git forks for those repos under the geonode git account, like this: >>> github.com/geonode/geoext >>> github.com/geonode/openlayers >>> github.com/geonode/geoserver >>> github.com/geonode/geonetwork >>> github.com/geonode/ext >>> github.com/geonode/gsconfig.py >>> >>> And put git submodules in this main repo: >>> github.com/geonode/geonode >>> >>> If anybody does not like the fact that we depend on Github, we always have the option to setup: >>> git.geonode.org >>> >>> 3 - We commit all SVN externals directly to the git repository, kind of like svn vendor branches. >>> Pros - even better integration than git submodule, when you checkout the project you get >>> everything. >>> Cons - it takes a bit of digging in the repository to extract diffs to submit upstream patches, and >>> even bringing in updates is kind of a pain. >>> >>> It is true this option may be the simplest for new users but I don't like the fact that patches are against "Geonode's version of X project" instead of the actual project. "Explicit is better than implicit", so #2 is still my favorite. >>> >>> But I'm open to alternatives/arguments. However, let's try and be git-friendly by, say, Friday next week? I'm not aware of a hard deadline but at the rate this discussion's been going we'll never get converted. >>> >>> +1 The sooner the better. >>> >>> Ariel >>> >> > -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.