From: Jeff Garzik <jgarzik@bitpay•com>
To: Btc Drak <btcdrak@gmail•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 10:20:47 -0500 [thread overview]
Message-ID: <CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com> (raw)
In-Reply-To: <CADJgMztRdNWyogPCjv64qpUHcvGDiOZDVAkv5Ra8hn25Z9xa8w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]
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/
[-- Attachment #2: Type: text/html, Size: 2448 bytes --]
next prev parent reply other threads:[~2014-12-15 15:21 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 [this message]
2014-12-15 18:42 ` Cory Fields
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=CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com \
--to=jgarzik@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=btcdrak@gmail$(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