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.
