<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 15, 2014 at 7:35 PM, Jeff Garzik <span dir="ltr">&lt;<a href="mailto:jgarzik@bitpay.com" target="_blank">jgarzik@bitpay.com</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>At a macro level, that cycle was repeated many times, leading to the opposite end result:  a lot of tiny movement/refactor/movement/refactor producing the review and patch annoyances described.<br></div><div><br></div><div>It produces a blizzard of new files and new data structures, breaking a bunch of out-of-tree patches, complicating review quite a bit.  If the vast majority of code movement is up front, followed by algebraic simplifications, followed by data structure work, further patches are easy to review/apply with less impact on unrelated code.</div><div><br></div><div>The flow of patches into the tree over time should be examined.  Simply tagging patches as movement-only does not address the described problem at all.<br></div></div></div></div></blockquote><div><br></div><div>I think we can all agree that if the process is made more friendly for reviewers, everyone wins. It&#39;s been hard to even know where everything is because it moves so often. e.g. In the last couple weeks stuff moved from core.h to core/block.h to primitive/block.h or something to that effect. Anyway, Jeff said this quite elegantly.</div></div></div></div>