Jeff Garzik [ARCHIVE] on Nostr: 📅 Original date posted:2014-12-15 📝 Original message:On Mon, Dec 15, 2014 at ...

📅 Original date posted:2014-12-15
📝 Original message:On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields <lists at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141215/e2cb4696/attachment.html>;