Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jgarzik@bitpay.com>) id 1Y0bQV-0001SB-6O
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Dec 2014 19:35:27 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.213.169 as permitted sender)
	client-ip=209.85.213.169; envelope-from=jgarzik@bitpay.com;
	helo=mail-ig0-f169.google.com; 
Received: from mail-ig0-f169.google.com ([209.85.213.169])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Y0bQU-00006S-4u
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Dec 2014 19:35:27 +0000
Received: by mail-ig0-f169.google.com with SMTP id hl2so6507937igb.4
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 15 Dec 2014 11:35:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=nHaMilYhBjEPlfN/KuUnknFb/Up2iZRKHKWiJFETfbw=;
	b=iyQ3k0BD26syU2CUAlZ7Bt7ISnFGESda411MksDCTTBKRFAojrwyCISXFX4CXAK84F
	4gkWS5r7fMNSIPQS+raFFQqp2KSiK6SbzfMs+LWI1AZsJWMJPifJ2IzhG0Ptz7qXqTLz
	ME9LS+T5jUSMAAL3OVohcTAFJ5bGeJkUVsw70hvXjWkjNrkvqFXBFIwY0yRn8YHXeLek
	uoSfvRKEi8PNhlChjkmDzp7h084PwiTxKJy8mq5OetJ+yzfwyXzlKmOoIjeB/H84br9j
	PxLFck7pMqfGYqHl+R5IbIEfr+0I412hEa62TyxZ2wVdx5Lrwti+wUcN5YHwmlHbxL+Q
	JBrw==
X-Gm-Message-State: ALoCoQkc8aOIvWf9tnAutG2C4FlsU3h4waZf7xotOa8rMFVKUJIE2OROtzpb5jZpIoHyyrJm9/x1
X-Received: by 10.50.143.37 with SMTP id sb5mr19203924igb.33.1418672120835;
	Mon, 15 Dec 2014 11:35:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.76 with HTTP; Mon, 15 Dec 2014 11:35:00 -0800 (PST)
In-Reply-To: <CAApLimi+Jskwn=70+cfqr8=d55CKJFpBDBmW48zJk24PSBZczg@mail.gmail.com>
References: <20141215124730.GA8321@savin.petertodd.org>
	<CADJgMztRdNWyogPCjv64qpUHcvGDiOZDVAkv5Ra8hn25Z9xa8w@mail.gmail.com>
	<CAJHLa0OvDPazCQVonhokm0KopN-WYj0_PP_LO8gPewc1LG5Qow@mail.gmail.com>
	<CAApLimi+Jskwn=70+cfqr8=d55CKJFpBDBmW48zJk24PSBZczg@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Mon, 15 Dec 2014 14:35:00 -0500
Message-ID: <CAJHLa0MDftgnxB5itQS2jKqZsPj2vg-=SM+jVqUDxKGRZjuukA@mail.gmail.com>
To: Cory Fields <lists@coryfields.com>
Content-Type: multipart/alternative; boundary=001a1135fe4ed0ecde050a46572b
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Y0bQU-00006S-4u
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Recent EvalScript() changes mean
 CHECKLOCKTIMEVERIFY can't be merged
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 19:35:27 -0000

--001a1135fe4ed0ecde050a46572b
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields <lists@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/

--001a1135fe4ed0ecde050a46572b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields <span dir=3D"=
ltr">&lt;<a href=3D"mailto:lists@coryfields.com" target=3D"_blank">lists@co=
ryfields.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div =
class=3D"h5"><span style=3D"color:rgb(34,34,34)">That&#39;s exactly what ha=
ppened during the modularization process, with</span><br></div></div>
the exception that the code movement and refactors happened in<br>
parallel rather than in series. But they _were_ done in separate<br>
logical chunks for the sake of easier review.<br></blockquote><div><br></di=
v><div>&quot;That&#39;s exactly what was done except it wasn&#39;t&quot;</d=
iv><div><br></div><div>Yes, in micro, at the pull request level, this happe=
ned</div><div>* Code movement</div><div>* Refactor</div><div><br></div><div=
>At a macro level, that cycle was repeated many times, leading to the oppos=
ite end result: =C2=A0a lot of tiny movement/refactor/movement/refactor pro=
ducing the review and patch annoyances described.</div><div><br></div><div>=
It produces a blizzard of new files and new data structures, breaking a bun=
ch of out-of-tree patches, complicating review quite a bit.=C2=A0 If the va=
st majority of code movement is up front, followed by algebraic simplificat=
ions, followed by data structure work, further patches are easy to review/a=
pply with less impact on unrelated code.</div><div><br></div><div>The flow =
of patches into the tree over time should be examined.=C2=A0 Simply tagging=
 patches as movement-only does not address the described problem at all.</d=
iv><div><br></div></div>-- <br><div class=3D"gmail_signature">Jeff Garzik<b=
r>Bitcoin core developer and open source evangelist<br>BitPay, Inc. =C2=A0 =
=C2=A0 =C2=A0<a href=3D"https://bitpay.com/" target=3D"_blank">https://bitp=
ay.com/</a></div>
</div></div>

--001a1135fe4ed0ecde050a46572b--