Currently we have no contact point for JavaScript related design/development questions and considerations for GeoNode. Chris has asked me to act as the JavaScript lead and help Seb and David keep an eye on the bigger picture of JavaScript (i.e. Ext JS, gxp, GeoExt and OpenLayers) use in GeoNode. To make this happen, I'd ask everyone with a task that requires JavaScript coding to check in with me. By doing so, it should be much easier to avoid duplicate efforts and share resources. Also, as it has previously happend e.g. at the NY sprint, please involve me in discussions on server side development that affect the way the web client consumes or transmits information. To document and spread the knowledge collected this way, I would like to maintain http://projects.opengeo.org/CAPRA/wiki/JavaScript. This page is currently rather empty, but should involve into a dashboard for JavaScript hints, goals, decisions etc. One more idea to make sure that we are all in sync: would it be possible for the NY team to send a short report of problems or observations that come up during the weekly live site update to the list? Please let me know if there are any doubts or ideas concerning JavaScript teamwork! Thanks, Andreas. -- Andreas Hocevar OpenGeo - http://opengeo.org/ Expert service straight from the developers.
Thanks for stepping up on this! > To make this happen, I'd ask everyone with a task that requires JavaScript > coding to check in with me. By doing so, it should be much easier to avoid > duplicate efforts and share resources. > David and I have been talking a lot about team process and how we can make DVCS work for us. One topic that came up was the idea of having topical repositories which are maintained by domain experts. So, for example, Andreas could maintain the GeoNode repository or branch that all major JS changes had to go through. Then we would pull from that repo/branch to the development or release branches. Just an idea. What are your thoughts on this? > Also, as it has previously happend e.g. at the NY sprint, please involve me > in discussions on server side development that affect the way the web client > consumes or transmits information. > > To document and spread the knowledge collected this way, I would like to > maintain http://projects.opengeo.org/CAPRA/wiki/JavaScript. This page is > currently rather empty, but should involve into a dashboard for JavaScript > hints, goals, decisions etc. > > One more idea to make sure that we are all in sync: would it be possible > for the NY team to send a short report of problems or observations that come > up during the weekly live site update to the list? > I'll take that responsibility. Great idea! -- Sebastian Benthall OpenGeo - http://opengeo.org
On 06/24/2010 04:43 PM, Sebastian Benthall wrote: > Thanks for stepping up on this! > > To make this happen, I'd ask everyone with a task that requires > JavaScript coding to check in with me. By doing so, it should be > much easier to avoid duplicate efforts and share resources. > > > David and I have been talking a lot about team process and how we can > make DVCS work for us. > > One topic that came up was the idea of having topical repositories > which are maintained by domain experts. So, for example, Andreas > could maintain the GeoNode repository or branch that all major JS > changes had to go through. Then we would pull from that repo/branch > to the development or release branches. > Mostly so that everyone can see what this would look like, I have used a forked repository instead of publishing a patch for the template refactoring suggested by Andreas earlier. Basically: It's easy to add a public repo with an arbitrary alias (so like, you can add my github repo as 'dwins' and pull from it with "git pull dwins branchname" instead of "git pull origin branchname".) This allows really simple branching for stuff that isn't ready for primetime yet, without ever requiring us to duplicate those branches in the "central" repository at all if the work doesn't pan out. Perhaps playing with this a bit would help folks to figure out what kind of git usage we are comfortable with. I put some specific instructions on the other thread along with some notes about the changes I made. -- David Winslow OpenGeo - http://opengeo.org/
On Jun 25, 2010, at 00:34 , David Winslow wrote: > On 06/24/2010 04:43 PM, Sebastian Benthall wrote: >> Thanks for stepping up on this! >> >> To make this happen, I'd ask everyone with a task that requires JavaScript coding to check in with me. By doing so, it should be much easier to avoid duplicate efforts and share resources. >> >> David and I have been talking a lot about team process and how we can make DVCS work for us. >> >> One topic that came up was the idea of having topical repositories which are maintained by domain experts. So, for example, Andreas could maintain the GeoNode repository or branch that all major JS changes had to go through. Then we would pull from that repo/branch to the development or release branches. This would be a workflow without a strict develop - review - commit cycle. So people could commit to a domain branch, and the domain expert would have to permanently review it? I think I like a ticket and review based approach better, but this might add too much overhead. Maybe we find something in between, e.g. accompany commits to this branch with (trac) tickets and ticket comments that have the domain expert on cc? Other ideas? > Mostly so that everyone can see what this would look like, I have used a forked repository instead of publishing a patch for the template refactoring suggested by Andreas earlier. Basically: It's easy to add a public repo with an arbitrary alias (so like, you can add my github repo as 'dwins' and pull from it with "git pull dwins branchname" instead of "git pull origin branchname".) This allows really simple branching for stuff that isn't ready for primetime yet, without ever requiring us to duplicate those branches in the "central" repository at all if the work doesn't pan out. I like this. It is more efficient than working with patches, and in github we can even add comments to changesets and code lines. We should, however, be able to link such branches to (trac) tickets somehow, for a similar workflow as tickets with patches that can be reviewed by other devs. Any ideas? The only way I can imagine is to link to github on a ticket, which is not so bad. Maybe other projects have solved this already? > Perhaps playing with this a bit would help folks to figure out what kind of git usage we are comfortable with. I put some specific instructions on the other thread along with some notes about the changes I made. Great stuff! Now I only have to get more comfortable with merging in git :-) -Andreas.
On 06/25/2010 10:10 AM, Andreas Hocevar wrote: > I like this. It is more efficient than working with patches, and in github we can even add comments to changesets and code lines. We should, however, be able to link such branches to (trac) tickets somehow, for a similar workflow as tickets with patches that can be reviewed by other devs. Any ideas? The only way I can imagine is to link to github on a ticket, which is not so bad. Maybe other projects have solved this already? > I don't see any problems with explicitly writing github links on a ticket (seems just as easy as attaching a patch to me). Another, perhaps complementary, practice would be to name branches in git after trac issues. So if you want to get the work I've done on issue #523, you just run: $ git fetch dwins issue-523 In combination with the github Fork Queue (http://github.com/blog/270-the-fork-queue) this could be a pretty lightweight way to deal with tracking tickets/branches. -- David Winslow OpenGeo - http://opengeo.org/
On Fri, Jun 25, 2010 at 9:10 AM, Andreas Hocevar <ahocevar@opengeo.org> wrote: > On Jun 25, 2010, at 00:34 , David Winslow wrote: > >> On 06/24/2010 04:43 PM, Sebastian Benthall wrote: >>> Thanks for stepping up on this! >>> >>> To make this happen, I'd ask everyone with a task that requires JavaScript coding to check in with me. By doing so, it should be much easier to avoid duplicate efforts and share resources. >>> >>> David and I have been talking a lot about team process and how we can make DVCS work for us. >>> >>> One topic that came up was the idea of having topical repositories which are maintained by domain experts. So, for example, Andreas could maintain the GeoNode repository or branch that all major JS changes had to go through. Then we would pull from that repo/branch to the development or release branches. > > This would be a workflow without a strict develop - review - commit cycle. So people could commit to a domain branch, and the domain expert would have to permanently review it? I think I like a ticket and review based approach better, but this might add too much overhead. Maybe we find something in between, e.g. accompany commits to this branch with (trac) tickets and ticket comments that have the domain expert on cc? Other ideas? Andreas, I think your concern can be addressed by the use of "pull requests", github interface allows it, but they can also be done via more traditional methods (email, irc). What I have in mind, is for example the following: "Ariel has a nice idea about how to improve the javascript generation based on Django templates, he pushes those commits to his `js-updates` branch": `http://github.com/ingenieroariel/geonode (branch js-updates)` and (depending on what is decided here): a. Uses the github interface to send a pull request to ``achocevar`` or ``geonode`` to check out his changes. b. Creates a ticket with the proposal and link to the branch. c. Sends an email to the mailing list about the change / proposal. (Like dwins did for the template refactor) and then: "Andreas reads the commit on github interface, gets a feel on what the code changes are about and pulls the changes to his local repo, merges them in the `js` branch and pushes them back to http://github.com/geonode/geonode (branch js) or (branch develop)." To summarize, I think it should be a "pull" based system instead of people constantly "push"ing commits to domain branches making core developers' life harder. Ariel
On 06/25/2010 10:46 AM, Ariel Nunez wrote: > On Fri, Jun 25, 2010 at 9:10 AM, Andreas Hocevar<ahocevar@opengeo.org> wrote: > >> On Jun 25, 2010, at 00:34 , David Winslow wrote: >> >> >>> On 06/24/2010 04:43 PM, Sebastian Benthall wrote: >>> >>>> Thanks for stepping up on this! >>>> >>>> To make this happen, I'd ask everyone with a task that requires JavaScript coding to check in with me. By doing so, it should be much easier to avoid duplicate efforts and share resources. >>>> >>>> David and I have been talking a lot about team process and how we can make DVCS work for us. >>>> >>>> One topic that came up was the idea of having topical repositories which are maintained by domain experts. So, for example, Andreas could maintain the GeoNode repository or branch that all major JS changes had to go through. Then we would pull from that repo/branch to the development or release branches. >>>> >> This would be a workflow without a strict develop - review - commit cycle. So people could commit to a domain branch, and the domain expert would have to permanently review it? I think I like a ticket and review based approach better, but this might add too much overhead. Maybe we find something in between, e.g. accompany commits to this branch with (trac) tickets and ticket comments that have the domain expert on cc? Other ideas? >> > Andreas, I think your concern can be addressed by the use of "pull > requests", github interface allows it, but they can also be done via > more traditional methods (email, irc). > > What I have in mind, is for example the following: > > "Ariel has a nice idea about how to improve the javascript generation > based on Django templates, he pushes those commits to his `js-updates` > branch": `http://github.com/ingenieroariel/geonode (branch > js-updates)` and (depending on what is decided here): > a. Uses the github interface to send a pull request to ``achocevar`` > or ``geonode`` to check out his changes. > b. Creates a ticket with the proposal and link to the branch. > c. Sends an email to the mailing list about the change / proposal. > (Like dwins did for the template refactor) > > and then: > > "Andreas reads the commit on github interface, gets a feel on what the > code changes are about and pulls the changes to his local repo, merges > them in the `js` branch and pushes them back to > http://github.com/geonode/geonode (branch js) or (branch develop)." > > To summarize, I think it should be a "pull" based system instead of > people constantly "push"ing commits to domain branches making core > developers' life harder. > > Ariel > Yes. I am not sure that github pull requests have a large advantage over trac tickets that link back to git repositories (they are not visible to anyone other than the sender and receiver, for example) but I definitely think that pulls by domain experts are a better approach than pushes from arbitrary contributors. Github's docs may help to clarify what a "pull request" actually is, for the unfamiliar: http://github.com/guides/pull-requests -- David Winslow OpenGeo - http://opengeo.org/