On 06/25/2010 10:46 AM, Ariel Nunez wrote: > On Fri, Jun 25, 2010 at 9:10 AM, Andreas Hocevar<[email protected]> 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/
