From: Cory Fields <lists@coryfields•com>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged
Date: Mon, 15 Dec 2014 13:42:27 -0500 [thread overview]
Message-ID: <CAApLimi+Jskwn=70+cfqr8=d55CKJFpBDBmW48zJk24PSBZczg@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com>
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
next prev parent reply other threads:[~2014-12-15 19:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 12:47 Peter Todd
2014-12-15 14:57 ` Btc Drak
2014-12-15 15:20 ` Jeff Garzik
2014-12-15 18:42 ` Cory Fields [this message]
2014-12-15 19:35 ` Jeff Garzik
2014-12-15 21:19 ` Cory Fields
2014-12-15 21:54 ` Jeff Garzik
2014-12-15 21:57 ` Btc Drak
2014-12-15 17:38 ` Gregory Maxwell
2014-12-15 17:46 ` Wladimir
2014-12-15 18:10 ` Pieter Wuille
2014-12-15 18:35 ` Cory Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAApLimi+Jskwn=70+cfqr8=d55CKJFpBDBmW48zJk24PSBZczg@mail.gmail.com' \
--to=lists@coryfields$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox