On Fri, Oct 04, 2013 at 12:30:07PM +0200, Mike Hearn wrote: > Git makes it easy to fork peoples work off and create long series of > commits that achieve some useful goal. That's great for many things. > Unfortunately, code review is not one of those things. > > I'd like to make a small request - when submitting large, complex pieces of > work for review, please either submit it as one giant squashed change, or > be an absolute fascist about keeping commits logically clean and separated. > It really sucks to review things in sequence and then discover that some > code you spent some time thinking about or puzzling out got > deleted/rewritten/changed in a later commit. It also can make it harder to > review things when later code uses new APIs or behaviour changes introduced > in earlier commits - you have to either keep it all in your head, do lots > of tab switching, or do a squash yourself (in which case every reviewer > would have to manually do that).
When I'm reviewing multiple commit pull-requests and want to see every change made, I always either click on the "Files Changed" tab on github, which collapses every commit into a single diff, or do the equivalent with git log. Why doesn't that work for you? > On a related note, github seems to have lost the plot with regards to code > review - they are spending their time adding 3D renderers to their diff > viewer but not making basic improvements other tools had for years. > > So, I'd like to suggest the idea of using Review Board: > > http://www.reviewboard.org/ > > It's an open source, dedicated code review tool used by lots of big name > companies for their internal work. It has git[hub] integration and a lot of > very neat features, like the ability to attach screenshots to reviews. Also > more basic ones, like side by side diffs. Branches can be and often are > submitted to the system as single reviews. > > The company behind it (disclosure - written and run by a long time friend > of mine) offers hosting plans, but we could also host it on a Foundation > server instead. One advantage of using github is that they're an independent third party; we should think carefully about the risks of furthering the impression that Bitcoin development is a closed process by moving the code review it to a server that we control with explicit review groups. Given that Review Board appears to remain cryptographically unverifiable there may also be disadvantages in operating it ourselves in that if the review server does get compromised we *don't* have a third-party to blame. In addition GitHub is a third-party with a very valuable reputation to uphold and full-time staff - they're doing a better job of keeping their servers secure and running then we ever could. -- 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
