[Twisted-Python] github, again

Tom Prince tom.prince at ualberta.net
Sat Jun 8 10:07:03 MDT 2013

When I first saw this, I was excited at the possibility of moving to git
(although this doesn't affect me, as I've been using git exclusively for months
already). On the other hand, I'm cautious about moving our workflow to github.

Although being able to comment on the diff inline is very convenient, my
experience is that this encourages looking at changes in a line-by-line fashion,
rather than looking at the overall design.  find that having to compose the
entire review at once leads to a more thoughtful review. So, while it is
convenient, there is a cost to it as well.

Being able to see what comments have been addressed is handy, I usually find
myself opening all the hidden comments, either to see if the change made address
the comment or to provide more context on the current state of the change
(particularly if I wasn't the original reviewer).

While I understand the appeal of being able to merge with a single click (and
wouldn't be opposed to a tool that does this), I'm not sure that github's
implementation is desirable.  I think there is value in composing meaningful
commit messages, for commits to trunk. While github supports this, it doesn't
encourage it. (I've been looking through buildbot's logs recently, and most
commits to master have the message "Merge branch '<branch-name>' of
git://github.com/<user>/buildbot"." Certainly some of this is social, I don't
think github provides any tools to help enforce this.

I'm not entirely sure how the hybrid workflow would make things easier. It seems
like one would need to look at two places for comments rather than just one;
even if all the comments on the code itself are on github, one will still need
to look at the history of the ticket to see any discussion of the design or
other consideration. Potentially more, if more than one person has worked on a
branch; unless everybody involved can push to the same repo, only a single
person can add commits to a specific pull request. For core developers, this
could just be the main repo, but for non-core developers (or when a core
developer takes over from an outside contributor), there will necessarily be
multiple pull requests for a single change.

I wonder how much of the issue that github solves could be addressed by other
means? Forcing a build is now two clicks from the ticket page, and diffs one. I
just discovered https://github.com/Automattic/trac-code-comments-plugin which
allows inline commenting. We could implement a tool to merge to trunk with a
properly formated commit message from the web. There is, of course, the question
of whether it worth the effort to implement this ourselves, when github exists.
That consideration has to be tempered with the fact that github imposes
restrictions on our workflow that seem to run counter to the philosophy of
twisted development.


More information about the Twisted-Python mailing list