> > Compare this to the Github way of doing things: > > 1. Commit messages can be seen as part of a pull request, others can add > inline comments/suggestions to each commit diff, and the pull request > author can add more commits in the same pull request to improve his/her > contribution because of the review. > > 2. Every developer or potential contributor only needs to do *one* clone > of the project's repo. Then he only needs to create branches in his > local copy and push them to Github to ask for a pull request. > I'm no GitHub expert, but if I'm not mistaken the exact same workflow described above is not only possible but actually very simple to implement in Google Code. In fact, it's designed to do just this. Perhaps a simple example would illustrate this best.
I created a personal server-side clone of the default repository here: http://code.google.com/r/jedludlow-spyderlib/ >From there I created an example commit (added a sarcastic comment only, no real code changes, humor intended) and pushed it to my clone: http://code.google.com/r/jedludlow-spyderlib/source/detail?r=2f5b59b6ced8020fbbf2f0cf555e2a32b25fc41a and initiated a code review *within* Google Code itself. You have to enable this on your personal clone under the Adminster tab. It's actually quite nice. You can add line by line comments to the diff: https://code.google.com/r/jedludlow-spyderlib/source/diff?spec=svn2f5b59b6ced8020fbbf2f0cf555e2a32b25fc41a&r=2f5b59b6ced8020fbbf2f0cf555e2a32b25fc41a&format=side&path=/bootstrap.py The review can even be opened to non-project members if you enable this under the Administer tab. While they aren't specifically called "pull requests" in Google Code, a pull request is created by creating a new Issue and using the "Code Review" template. Here's the issue I created to match: https://code.google.com/p/spyderlib/issues/detail?id=904 This should trigger a review and evaluation. If the change were accepted, someone with commit rights to the default repository would simply pull changes from this clone and merge them into the default repo. Today, it looks like the majority of development is done directly in the default repo. A minor modification in the workflow would I think produce the result we are looking for without all the overhead of switching hosting and all the associated loss of history that would occur. If *all* developers were working from personal clones (and you really need only one because you can branch inside it and keep your clone trunk in sync with the default repo trunk) that had code review enabled, it would allow for all changes to be reviewed right in Google Code *before* being pushed to the default repo. There isn't any bandwidth hit because you don't need local copies of all the clones. Instead, those with default repo commit access simply point to whichever clone *on the server* that you need to pull from when you need to update the default repo. Even if the move to Github doesn't attract more contributors, I think it > will really improve our code quality and testing because we will be more > aware of what other devs are trying to do and maybe we could easily > avoid things like Issues 740, 863 or 880, which required more testing > and communication between us. > As an open source project, contributors emerge out of satisfied users, and nothing brings more satisfied users than a steady stream of tangible new features in the software itself. I would see the move to GitHub as a distraction from this primary goal particularly where Google Code seems to facilitate the same workflow (create a clone, branch inside your clone, develop, push to server-side clone, code review, and then push to default). It would just require a subtle shift toward developers working in personal clones. -- You received this message because you are subscribed to the Google Groups "spyder" group. To view this discussion on the web visit https://groups.google.com/d/msg/spyderlib/-/JMlUm4eXEv0J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/spyderlib?hl=en.
