On 11/19/2010 09:37 AM, Fernando Perez wrote: > On Fri, Nov 19, 2010 at 12:22 AM, Dag Sverre Seljebotn > <[email protected]> wrote: > >> Out of ignorance: Just how interlinked is the code review process with >> the issue tracker? Do you typically link code review up to tickets in >> some way, or are pull requests completely standalone? >> > When a pull request is made, an issue is automatically created by > github that links to the pull request. E.g.: > > https://github.com/ipython/ipython/pull/199 > https://github.com/ipython/ipython/issues/199 > > If the pull request is merged *without rebasing* (by following > something like the 3 steps given at the bottom of the request page) , > github automatically notices that the commits from the request went > in, and closes both the request and the issue for you without the > need for any extra action. The act of pushing causes the closing of > all. > > If you do rebase, github can't tell that you did merge the contents, > so you'll have to click manually on the close button yourself (but > closing the request auto-closes the associated bug history as well). > > Pull request pages remain available even after closed, so any > discussion that takes place during a pull request (which often > involves useful design discussions) remains accessible later on. This > is something I think is very useful and I'm glad they thought of it > (e.g. on launchpad, closed merge requests were very hard to find: they > didn't get deleted, but there was nothing in the interface to find > them unless you *manually* had made a bug for it to fish it back out > later. Awful). > > In summary, pull/issue linking is: > - automatic for opening, > - automatic for no-rebase closing > -if rebase did happen, you only need to manually close one for both to > get closed. > > >> With e.g. Google Code it seems we'd need to host the web page and >> perhaps the wiki elsewhere (as Ondrej noted, the wiki on Google Code is >> only editable by project members), so hosting the bug tracker somewhere >> else and use github for the rest doesn't seem so bad. >> > It's worth noting what Ondrej pointed out in his blog review: since > github lets you host both the wiki and the webpages with more flexible > controls (everything is a repo), you could get the whole thing on > github. > > One more nice thing about having the issues at github, is that any > commit that closes a bug only needs to say 'closes gh-NNN' or 'closes > #NNN', and github will > > - automatically close the bug > - make a link at the closed bug page to the commit page > - make a link at the commit entry to the bug > > See for example: > > https://github.com/ipython/ipython/issues/148 > https://github.com/ipython/ipython/commit/a55b74a629425e3344c8bad7b5994ebfc5b12085 > > This is very handy, because you know that the moment that commit gets > pushed, everything will be automatically get taken care of. > > This good integration between commits and issues is a point in favor > of keeping the issue hosting at github, despite the limnitations I > complained about earlier. >
Thanks again. Seems to me that if the limitations of GitHub is primarily in getting reports (one can always create tags for each milestone, tags for each component, and so on). And with an open API, I assume that making reports is something one could do on a seperate page outside of GitHub's control (say, on appspot.google.com). As long as I had a simple webapp that would take all tags starting with "Milestone" and group tickets by them, that would fill 80% of my needs from Trac. But that seems like a half hour script once one knows the API. Of course, I don't want that to be *my* half hour... I'd love to stumble over somebody's extensive suite of reporting tools for GitHub issues :-) Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
