MIME-Version: 1.0
In-Reply-To: <CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com>
References: <20141215124730.GA8321@savin.petertodd.org>
	<CADJgMztRdNWyogPCjv64qpUHcvGDiOZDVAkv5Ra8hn25Z9xa8w@mail.gmail.com>
	<CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com>
Date: Mon, 15 Dec 2014 13:42:27 -0500
Message-ID: <CAApLimi+Jskwn=70+cfqr8=d55CKJFpBDBmW48zJk24PSBZczg@mail.gmail.com>
From: Cory Fields <lists@coryfields.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean
 CHECKLOCKTIMEVERIFY can't be merged
Precedence: list

On Mon, Dec 15, 2014 at 10:20 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> On Mon, Dec 15, 2014 at 9:57 AM, Btc Drak <btcdrak@gmail.com> wrote:
>>
>> We all want to see more modular code, but the first steps should just be
>> to relocate blocks of code so everything is more logically organised in
>> smaller files (especially for consensus critical code). Refactoring should
>> come in a second wave preferably after a stable release.
>
>
> This is my opinion as well.  In the Linux kernel, we often were faced with a
> situation where you have a One Big File driver with > 1MB of source code.
> The first step was -always- raw code movement, a brain-dead breaking up of
> code into logical source code files.
>
> Refactoring of data structures comes after that.
>
> While not always money-critical, these drivers Had To Keep Working.  We had
> several situations where we had active users, but zero hardware access for
> debugging, and zero access to the vendor knowledge (hardware documentation,
> engineers).  Failure was not an option.  ;p
>
> Performing the dumb Break Up Files step first means that future, more
> invasive data structures are easier to review, logically segregated, and not
> obscured by further code movement changes down the line.  In code such as
> Bitcoin Core, it is important to think about the _patch stream_ and how to
> optimize for reviewer bandwidth.
>
> The current stream of refactoring is really a turn-off in terms of
> reviewing, sapping reviewer bandwidth by IMO being reviewer-unfriendly.  It
> is a seemingly never-ending series of tiny
> refactor-and-then-stuff-in-a-class-and-make-it-pretty-and-do-all-the-work.
> Some change is in order, gentlemen.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/

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. The commit tag
"MOVEONLY" developed organically out of this process, and a grep of
the 0.10 branch for "MOVEONLY" is a testament to exactly how much code
moved 1:1 out of huge files and into logically separated places and/or
new files.

Perhaps it's worth making "MOVEONLY" (which as the name implies, means
that code has been copied 1:1 to a new location) use an official dev
guideline for use in future refactors.

Cory