path: root/c1/26a781839ea5681ee0627e280f0d57ed933c62

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <21xe14@gmail.com>) id 1Y1U4Y-0005rw-Um
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Dec 2014 05:56:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.196 as permitted sender)
	client-ip=209.85.212.196; envelope-from=21xe14@gmail.com;
	helo=mail-wi0-f196.google.com; 
Received: from mail-wi0-f196.google.com ([209.85.212.196])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Y1U4W-0008FP-Cp
	for bitcoin-development@lists.sourceforge.net;
	Thu, 18 Dec 2014 05:56:26 +0000
Received: by mail-wi0-f196.google.com with SMTP id ex7so238205wid.11
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 17 Dec 2014 21:56:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.218.133 with SMTP id pg5mr20893739wic.70.1418882178318; 
	Wed, 17 Dec 2014 21:56:18 -0800 (PST)
Received: by 10.27.131.17 with HTTP; Wed, 17 Dec 2014 21:56:18 -0800 (PST)
In-Reply-To: <CAJHLa0M0YeEWWaP4gNpwnaDq56w=AHW_kmLr=f3AVvHDB89SNA@mail.gmail.com>
References: <CAJHLa0M0YeEWWaP4gNpwnaDq56w=AHW_kmLr=f3AVvHDB89SNA@mail.gmail.com>
Date: Thu, 18 Dec 2014 05:56:18 +0000
Message-ID: <CAFZQHkHPoWBK5nq3DYFWUrSTTbqYn+x+DzwpGUxmWHSyJ6bgzw@mail.gmail.com>
From: 21E14 <21xe14@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=001a1135eac237863a050a7740a7
X-Spam-Score: -0.3 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(21xe14[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (21xe14[at]gmail.com)
	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: 1Y1U4W-0008FP-Cp
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Open development processes and reddit
	charms
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: Thu, 18 Dec 2014 05:56:27 -0000

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

I'll pick up where you left off, Jeff. The thought process behind the
Bitcoin Core threading model, platform support, libification, dependency
management, core data structures, DoS mitigation, script evolution,
scalability roadmap... just to scratch the surface, is likely never going
to be apparent entirely from the source code itself, and will not, in its
current form, be easily understood before digesting repository docs, repo
issues, pull requests, IRC logs, mailing list archives (open and closed),
forum posts, wiki articles, historical repositories, the foundation's
technical blog, whitepapers, to name a few. I'd rather not guess how many
have got a grip on it. If any, across the entire spectrum. It may be the
bottleneck to address. I encourage everyone to take a look at the C#
Language Design Notes* on codeplex. We'll know we've met the challenge when
folks are no longer digging up gmaxwell's IRC comments to understand the
rationale on nScriptCheckThreads, nor having to refer to sipa's
stackexchange to figure out chainstate & blockindex key/value pairs.

*
https://roslyn.codeplex.com/wikipage?title=CSharp%20Language%20Design%20Notes&referringTitle=Documentation


On Tue, Dec 16, 2014 at 5:59 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>
>
> It can be useful to review open source development processes from time to
> time.  This reddit thread[1] serves use both as a case study, and also a
> moment of OSS process introduction for newbies.
> [1]
> http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/
>
>
>
>
> *Dirty Laundry*
> When building businesses or commercial software projects, outsiders
> typically hear little about the internals of project development.  The
> public only hears what the companies release, which is prepped and
> polished. Internal disagreements, schedule slips, engineer fistfights are
> all unseen.
>
> Open source development is the opposite.  The goal is radical
> transparency.  Inevitably there is private chatter (0day bugs etc.), but
> the default is openness.  This means that is it normal practice to "air
> dirty laundry in public."  Engineers will disagree, sometimes quietly,
> sometimes loudly, sometimes rudely and with ad hominem attacks.  On the
> Internet, there is a pile-on effect, where informed and uninformed
> supporters add their 0.02 BTC.
>
> Competing interests cloud the issues further.  Engineers are typically
> employed by an organization, as a technology matures.  Those organizations
> have different strategies and motivations.  These organizations will
> sponsor work they find beneficial.  Sometimes those orgs are non-profit
> foundations, sometimes for-profit corporations.  Sometimes that work is
> maintenance ("keep it running"), sometimes that work is developing new,
> competitive features that company feels will give it a better market
> position.  In a transparent development environment, all parties are
> hyperaware of these competing interests.  Internet natterers painstakingly
> document and repeat every conspiracy theory about Bitcoin Foundation,
> Blockstream, BitPay, various altcoin developers, and more as a result of
> these competing interests.
>
> Bitcoin and altcoin development adds an interesting new dimension.
> Sometimes engineers have a more direct conflict of interest, in that the
> technology they are developing is also potentially their road to instant
> $millions.  Investors, amateur and professional, have direct stakes in a
> certain coin or coin technology.  Engineers also have an emotional stake in
> technology they design and nurture.  This results in incentives where
> supporters of a non-bitcoin technology work very hard to thump bitcoin.
> And vice versa.  Even inside bitcoin, you see "tree chains vs. side chains"
> threads of a similar stripe.  This can lead to a very skewed debate.
>
> That should not distract from the engineering discussion.  Starting from
> first principles, Assume Good Faith[2].  Most engineers in open source tend
> to mean what they say.  Typically they speak for themselves first, and
> their employers value that engineer's freedom of opinion.  Pay attention to
> the engineers actually working on the technology, and less attention to the
> noise bubbling around the Internet like the kindergarten game of grapevine.
> [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
>
> Being open and transparent means engineering disagreements happen in
> public.  This is normal.  Open source engineers live an aquarium life[3].
> [3] https://www.youtube.com/watch?v=QKe-aO44R7k
>
>
>
>
> *What the fork?*
> In this case, a tweet suggests consensus bug risks, which reddit account
> "treeorsidechains" hyperbolizes into a dramatic headline[1].  However, the
> headline would seem to be the opposite of the truth.  Several changes were
> merged during 0.10 development which move snippets of source code into new
> files and new sub-directories.  The general direction of this work is
> creating a "libconsensus" library that carefully encapsulates consensus
> code in a manner usable by external projects.  This is a good thing.
>
> The development was performed quite responsible:  Multiple developers
> would verify each cosmetic change, ensuring no behavior changes had been
> accidentally (or maliciously!) introduced.  Each pull request receives a
> full multi-platform build + automated testing, over and above individual
> dev testing.  Comparisons at the assembly language level were sometimes
> made in critical areas, to ensure zero before-and-after change.  Each
> transformation gets the Bitcoin Core codebase to a more sustainable, more
> reusable state.
>
> Certainly zero-change is the most conservative approach. Strictly
> speaking, that has the lowest consensus risk.  But that is a short term
> mentality.  Both Bitcoin Core and the larger ecosystem will benefit when
> the "hairball" pile of source code is cleaned up.  Progress has been made
> on that front in the past 2 years, and continues.   *Long term*, combined
> with the "libconsensus" work, that leads to less community-wide risk.
>
> The key is balance.  Continue software engineering practices -- like those
> just mentioned above -- that enable change with least consensus risk.  Part
> of those practices is review at each step of the development process:
> social media thought bubble, mailing list post, pull request, git merge,
> pre-release & release.  It probably seems chaotic at times.  In effect,
> git[hub] and the Internet enable a dynamic system of review and feedback,
> where each stage provides a check-and-balance for bad ideas and bad
> software changes.  It's a human process, designed to acknowledge and handle
> that human engineers are fallible and might make mistakes (or be
> coerced/under duress!).  History and field experience will be the ultimate
> judge, but I think Bitcoin Core is doing good on this score, all things
> considered.
>
> At the end of the day, while no change is without risk, version 0.10 work
> was done with attention to consensus risk at multiple levels (not just
> short term).
>
>
>
>
> *Technical and social debt*
> Working on the Linux kernel was an interesting experience that combined
> git-driven parallel development and a similar source code hairball.  One of
> the things that quickly became apparent is that cosmetic patches,
> especially code movement, was hugely disruptive.  Some even termed it
> anti-social.  To understand why, it is important to consider how modern
> software changes are developed:
>
> Developers work in parallel on their personal computers to develop XYZ
> change, then submit their change "upstream" as a github pull request.  Then
> time passes.  If code movement and refactoring changes are accepted
> upstream before XYZ, then the developer is forced update XYZ -- typically
> trivial fixes, re-review XYZ, and re-test XYZ to ensure it remains in a
> known-working state.
>
> Seemingly cosmetic changes such as code movement have a ripple effect on
> participating developers, and wider developer community.  Every developer
> who is *not* immediately merged upstream must bear the costs of updating
> their unmerged work.
>
> Normally, this is expected.  Encouraging developers to build on top of
> "upstream" produces virtuous cycles.
>
> However, a constant stream of code movement and cosmetic changes may
> produce a constant stream of disruption to developers working on
> non-trivial features that take a bit longer to develop before going
> upstream.  Trivial changes are encouraged, and non-trivial changes face a
> binary choice of (a) be merged immediately or (b) bear added re-base,
> re-view, re-test costs.
>
> Taken over a timescale of months, I argue that a steady stream of cosmetic
> code movement changes serves as a disincentive to developers working with
> upstream.  Each upstream breakage has a ripple effect to all developers
> downstream, and imposes some added chance of newly introduced bugs on
> downstream developers.  I'll call this "social debt", a sort of technical
> debt[4] for developers.
> [4] http://en.wikipedia.org/wiki/Technical_debt
>
> As mentioned above, the libconsensus and code movement work is a net
> gain.  The codebase needs cleaning up.  Each change however incurs a little
> bit of social debt.  Life is a little bit harder on people trying to get
> work into the tree.  Developers are a little bit more discouraged at the
> busy-work they must perform.  Non-trivial pull requests take a little bit
> longer to approve, because they take a little bit more work to rebase
> (again).
>
> A steady flow of code movement and cosmetic breakage into the tree may be
> a net gain, but it also incurs a *lot* of social debt.  In such
> situations, developers find that tested, working out-of-tree code
> repeatedly stops working *during the process of trying to get that work
> in-tree*.  Taken over time, it discourages working on the tree.  It is
> rational to sit back, *not* work on the tree, let the breakage stop, and
> then pick up the pieces.
>
>
>
>
> *Paradox Unwound*
> Bitcoin Core, then, is pulled in opposite directions by a familiar
> problem.  It is generally agreed that the codebase needs further
> refactoring.  That's not just isolated engineer nit-picking.  However, for
> non-trivial projects, refactoring is always anti-social in the short term.
> It impacts projects other than your own, projects you don't even know
> about. One change causes work for N developers.  Given these twin opposing
> goals, the key, as ever, is finding the right balance.
>
> Much like "feature freeze" in other software projects, developing a policy
> that opens and closes windows for code movement and major disruptive
> changes seems prudent.  One week of code movement & cosmetics followed by 3
> weeks without, for example.  Part of open source parallel development is *social
> signalling*:  Signal to developers when certain changes are favored or
> not, then trust they can handle the rest from there.
>
> While recent code movement commits themselves are individually ACK-worthy,
> professionally executed and moving towards a positive goal, I think the
> project could strike a better balance when it comes to disruptive cosmetic
> changes, a balance that better encourages developers to work on more
> involved Bitcoin Core projects.
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

<div dir=3D"ltr">I&#39;ll pick up where you left off, Jeff. The thought pro=
cess behind the Bitcoin Core threading model, platform support, libificatio=
n, dependency management, core data structures, DoS mitigation, script evol=
ution, scalability roadmap... just to scratch the surface, is likely never =
going to be apparent entirely from the source code itself, and will not, in=
 its current form, be easily understood before digesting repository docs, r=
epo issues, pull requests, IRC logs, mailing list archives (open and closed=
), forum posts, wiki articles, historical repositories, the foundation&#39;=
s technical blog, whitepapers, to name a few. I&#39;d rather not guess how =
many have got a grip on it. If any, across the entire spectrum. It may be t=
he bottleneck to address. I encourage everyone to take a look at the C# Lan=
guage Design Notes* on codeplex. We&#39;ll know we&#39;ve met the challenge=
 when folks are no longer digging up gmaxwell&#39;s IRC comments to underst=
and the rationale on nScriptCheckThreads, nor having to refer to sipa&#39;s=
 stackexchange to figure out chainstate &amp; blockindex key/value pairs.<b=
r><br>* <a href=3D"https://roslyn.codeplex.com/wikipage?title=3DCSharp%20La=
nguage%20Design%20Notes&amp;referringTitle=3DDocumentation">https://roslyn.=
codeplex.com/wikipage?title=3DCSharp%20Language%20Design%20Notes&amp;referr=
ingTitle=3DDocumentation</a><br><br></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Tue, Dec 16, 2014 at 5:59 PM, Jeff Garzik <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jg=
arzik@bitpay.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div><div><div><div><div><br></div>It can be useful to revi=
ew open source development processes from time to time.=C2=A0 This reddit t=
hread[1] serves use both as a case study, and also a moment of OSS process =
introduction for newbies.<br>[1] <a href=3D"http://www.reddit.com/r/Bitcoin=
/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/" target=
=3D"_blank">http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_s=
aying_shoddy_development_on_v010/</a><br><br><br></div><div><b>Dirty Laundr=
y<br><br></b></div>When building businesses or commercial software projects=
, outsiders typically hear little about the internals of project developmen=
t.=C2=A0 The public only hears what the companies release, which is prepped=
 and polished. Internal disagreements, schedule slips, engineer fistfights =
are all unseen.<br><br></div>Open source development is the opposite.=C2=A0=
 The goal is radical transparency.=C2=A0 Inevitably there is private chatte=
r (0day bugs etc.), but the default is openness.=C2=A0 This means that is i=
t normal practice to &quot;air dirty laundry in public.&quot;=C2=A0 Enginee=
rs will disagree, sometimes quietly, sometimes loudly, sometimes rudely and=
 with ad hominem attacks.=C2=A0 On the Internet, there is a pile-on effect,=
 where informed and uninformed supporters add their 0.02 BTC.<br><br></div>=
Competing interests cloud the issues further.=C2=A0 Engineers are typically=
 employed by an organization, as a technology matures.=C2=A0 Those organiza=
tions have different strategies and motivations.=C2=A0 These organizations =
will sponsor work they find beneficial.=C2=A0 Sometimes those orgs are non-=
profit foundations, sometimes for-profit corporations.=C2=A0 Sometimes that=
 work is maintenance (&quot;keep it running&quot;), sometimes that work is =
developing new, competitive features that company feels will give it a bett=
er market position.=C2=A0 In a transparent development environment, all par=
ties are hyperaware of these competing interests.=C2=A0 Internet natterers =
painstakingly document and repeat every conspiracy theory about Bitcoin Fou=
ndation, Blockstream, BitPay, various altcoin developers, and more as a res=
ult of these competing interests.<br><br></div>Bitcoin and altcoin developm=
ent adds an interesting new dimension.=C2=A0 Sometimes engineers have a mor=
e direct conflict of interest, in that the technology they are developing i=
s also potentially their road to instant $millions.=C2=A0 Investors, amateu=
r and professional, have direct stakes in a certain coin or coin technology=
.=C2=A0 Engineers also have an emotional stake in technology they design an=
d nurture.=C2=A0 This results in incentives where supporters of a non-bitco=
in technology work very hard to thump bitcoin.=C2=A0 And vice versa.=C2=A0 =
Even inside bitcoin, you see &quot;tree chains vs. side chains&quot; thread=
s of a similar stripe.=C2=A0 This can lead to a very skewed debate.<br><br>=
That should not distract from the engineering discussion.=C2=A0 Starting fr=
om first principles, Assume Good Faith[2].=C2=A0 Most engineers in open sou=
rce tend to mean what they say.=C2=A0 Typically they speak for themselves f=
irst, and their employers value that engineer&#39;s freedom of opinion.=C2=
=A0 Pay attention to the engineers actually working on the technology, and =
less attention to the noise bubbling around the Internet like the kindergar=
ten game of grapevine.<br>[2] <a href=3D"http://en.wikipedia.org/wiki/Wikip=
edia:Assume_good_faith" target=3D"_blank">http://en.wikipedia.org/wiki/Wiki=
pedia:Assume_good_faith</a><br><br></div><div>Being open and transparent me=
ans engineering disagreements happen in public.=C2=A0 This is normal.=C2=A0=
 Open source engineers live an aquarium life[3].<br>[3] <a href=3D"https://=
www.youtube.com/watch?v=3DQKe-aO44R7k" target=3D"_blank">https://www.youtub=
e.com/watch?v=3DQKe-aO44R7k</a><br><br><br></div><div><b>What the fork?<br>=
<br></b></div><div>In this case, a tweet suggests consensus bug risks, whic=
h reddit account &quot;treeorsidechains&quot; hyperbolizes into a dramatic =
headline[1].=C2=A0 However, the headline would seem to be the opposite of t=
he truth.=C2=A0 Several changes were merged during 0.10 development which m=
ove snippets of source code into new files and new sub-directories.=C2=A0 T=
he general direction of this work is creating a &quot;libconsensus&quot; li=
brary that carefully encapsulates consensus code in a manner usable by exte=
rnal projects.=C2=A0 This is a good thing.<br><br></div><div>The developmen=
t was performed quite responsible:=C2=A0 Multiple developers would verify e=
ach cosmetic change, ensuring no behavior changes had been accidentally (or=
 maliciously!) introduced.=C2=A0 Each pull request receives a full multi-pl=
atform build + automated testing, over and above individual dev testing.=C2=
=A0 Comparisons at the assembly language level were sometimes made in criti=
cal areas, to ensure zero before-and-after change.=C2=A0 Each transformatio=
n gets the Bitcoin Core codebase to a more sustainable, more reusable state=
.<br><br></div><div>Certainly zero-change is the most conservative approach=
. Strictly speaking, that has the lowest consensus risk.=C2=A0 But that is =
a short term mentality.=C2=A0 Both Bitcoin Core and the larger ecosystem wi=
ll benefit when the &quot;hairball&quot; pile of source code is cleaned up.=
=C2=A0 Progress has been made on that front in the past 2 years, and contin=
ues. =C2=A0 <i>Long term</i>, combined with the &quot;libconsensus&quot; wo=
rk, that leads to less community-wide risk.<br><br>The key is balance.=C2=
=A0 Continue software engineering practices -- like those just mentioned ab=
ove -- that enable change with least consensus risk.=C2=A0 Part of those pr=
actices is review at each step of the development process:=C2=A0 social med=
ia thought bubble, mailing list post, pull request, git merge, pre-release =
&amp; release.=C2=A0 It probably seems chaotic at times.=C2=A0 In effect, g=
it[hub] and the Internet enable a dynamic system of review and feedback, wh=
ere each stage provides a check-and-balance for bad ideas and bad software =
changes.=C2=A0 It&#39;s a human process, designed to acknowledge and handle=
 that human engineers are fallible and might make mistakes (or be coerced/u=
nder duress!).=C2=A0 History and field experience will be the ultimate judg=
e, but I think Bitcoin Core is doing good on this score, all things conside=
red.<br><br></div><div>At the end of the day, while no change is without ri=
sk, version 0.10 work was done with attention to consensus risk at multiple=
 levels (not just short term).<br><br><br></div><div><b>Technical and socia=
l debt<br><br></b></div><div>Working on the Linux kernel was an interesting=
 experience that combined git-driven parallel development and a similar sou=
rce code hairball.=C2=A0 One of the things that quickly became apparent is =
that cosmetic patches, especially code movement, was hugely disruptive.=C2=
=A0 Some even termed it anti-social.=C2=A0 To understand why, it is importa=
nt to consider how modern software changes are developed:<br><br></div><div=
>Developers work in parallel on their personal computers to develop XYZ cha=
nge, then submit their change &quot;upstream&quot; as a github pull request=
.=C2=A0 Then time passes.=C2=A0 If code movement and refactoring changes ar=
e accepted upstream before XYZ, then the developer is forced update XYZ -- =
typically trivial fixes, re-review XYZ, and re-test XYZ to ensure it remain=
s in a known-working state.<br><br></div><div>Seemingly cosmetic changes su=
ch as code movement have a ripple effect on participating developers, and w=
ider developer community.=C2=A0 Every developer who is <i>not</i> immediate=
ly merged upstream must bear the costs of updating their unmerged work.</di=
v><div><br></div><div>Normally, this is expected.=C2=A0 Encouraging develop=
ers to build on top of &quot;upstream&quot; produces virtuous cycles.<br><b=
r></div><div>However, a constant stream of code movement and cosmetic chang=
es may produce a constant stream of disruption to developers working on non=
-trivial features that take a bit longer to develop before going upstream.=
=C2=A0 Trivial changes are encouraged, and non-trivial changes face a binar=
y choice of (a) be merged immediately or (b) bear added re-base, re-view, r=
e-test costs.<br><br></div><div>Taken over a timescale of months, I argue t=
hat a steady stream of cosmetic code movement changes serves as a disincent=
ive to developers working with upstream.=C2=A0 Each upstream breakage has a=
 ripple effect to all developers downstream, and imposes some added chance =
of newly introduced bugs on downstream developers.=C2=A0 I&#39;ll call this=
 &quot;social debt&quot;, a sort of technical debt[4] for developers.<br>[4=
] <a href=3D"http://en.wikipedia.org/wiki/Technical_debt" target=3D"_blank"=
>http://en.wikipedia.org/wiki/Technical_debt</a><br></div><div><br></div><d=
iv>As mentioned above, the libconsensus and code movement work is a net gai=
n.=C2=A0 The codebase needs cleaning up.=C2=A0 Each change however incurs a=
 little bit of social debt.=C2=A0 Life is a little bit harder on people try=
ing to get work into the tree.=C2=A0 Developers are a little bit more disco=
uraged at the busy-work they must perform.=C2=A0 Non-trivial pull requests =
take a little bit longer to approve, because they take a little bit more wo=
rk to rebase (again).<br><br></div><div>A steady flow of code movement and =
cosmetic breakage into the tree may be a net gain, but it also incurs a <i>=
lot</i> of social debt.=C2=A0 In such situations, developers find that test=
ed, working out-of-tree code repeatedly stops working <i>during the process=
 of trying to get that work in-tree</i>.=C2=A0 Taken over time, it discoura=
ges working on the tree.=C2=A0 It is rational to sit back, <i>not</i> work =
on the tree, let the breakage stop, and then pick up the pieces.<br></div><=
div><b><br><br></b></div><div><b>Paradox Unwound<br><br></b></div><div>Bitc=
oin Core, then, is pulled in opposite directions by a familiar problem.=C2=
=A0 It is generally agreed that the codebase needs further refactoring.=C2=
=A0 That&#39;s not just isolated engineer nit-picking.=C2=A0 However, for n=
on-trivial projects, refactoring is always anti-social in the short term.=
=C2=A0 It impacts projects other than your own, projects you don&#39;t even=
 know about. One change causes work for N developers.=C2=A0 Given these twi=
n opposing goals, the key, as ever, is finding the right balance.<br><br></=
div><div>Much like &quot;feature freeze&quot; in other software projects, d=
eveloping a policy that opens and closes windows for code movement and majo=
r disruptive changes seems prudent.=C2=A0 One week of code movement &amp; c=
osmetics followed by 3 weeks without, for example.=C2=A0 Part of open sourc=
e parallel development is <i>social signalling</i>:=C2=A0 Signal to develop=
ers when certain changes are favored or not, then trust they can handle the=
 rest from there.<br><br></div><div>While recent code movement commits them=
selves are individually ACK-worthy, professionally executed and moving towa=
rds a positive goal, I think the project could strike a better balance when=
 it comes to disruptive cosmetic changes, a balance that better encourages =
developers to work on more involved Bitcoin Core projects.<span class=3D"HO=
EnZb"><font color=3D"#888888"><br><br></font></span></div><span class=3D"HO=
EnZb"><font color=3D"#888888"><div><b><br></b></div><div>-- <br></div><div>=
<div><div><div><div><div><div><div><div>Jeff Garzik<br>Bitcoin core develop=
er and open source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=
=3D"https://bitpay.com/" target=3D"_blank">https://bitpay.com/</a></div>
</div></div></div></div></div></div></div></div></font></span></div>
<br>-----------------------------------------------------------------------=
-------<br>
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br>
from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br=
>
with Interactivity, Sharing, Native Excel Exports, App Integration &amp; mo=
re<br>
Get technology previously reserved for billion-dollar corporations, FREE<br=
>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D164703151&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D164703151&amp;iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div></div>

--001a1135eac237863a050a7740a7--