1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
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"><<a href=3D"mailto:lists@coryfields.com" target=3D"_blank">lists@co=
ryfields.com</a>></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'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>"That's exactly what was done except it wasn't"</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--
|
