On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields <li...@coryfields.com> wrote:
> That's exactly what happened during the modularization process, with
> the exception that the code movement and refactors happened in
> parallel rather than in series. But they _were_ done in separate
> logical chunks for the sake of easier review.
>
"That's exactly what was done except it wasn't"
Yes, in micro, at the pull request level, this happened
* Code movement
* Refactor
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.
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.
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.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
