From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5WcS-000534-Go for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 10:00:24 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.182 as permitted sender) client-ip=209.85.212.182; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f182.google.com; Received: from mail-wi0-f182.google.com ([209.85.212.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5WcR-0006ip-7q for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 10:00:24 +0000 Received: by wicnd19 with SMTP id nd19so55138648wic.1 for ; Thu, 18 Jun 2015 03:00:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.209.130 with SMTP id mm2mr13882301wjc.64.1434621617236; Thu, 18 Jun 2015 03:00:17 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 03:00:17 -0700 (PDT) In-Reply-To: <55828737.6000007@riseup.net> References: <55828737.6000007@riseup.net> Date: Thu, 18 Jun 2015 12:00:17 +0200 X-Google-Sender-Auth: 6uhhfKil_MX3DsC4mZ231cLS_h4 Message-ID: From: Mike Hearn To: odinn Content-Type: multipart/alternative; boundary=047d7b3a82e2e1ef050518c7df05 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Z5WcR-0006ip-7q Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 10:00:24 -0000 --047d7b3a82e2e1ef050518c7df05 Content-Type: text/plain; charset=UTF-8 Dude, calm down. I don't have commit access to Bitcoin Core and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. So why did I say it? Because it's consistent with what I've always said: you cannot run a codebase like Wikipedia. Maintainers have to take part in debates, and then make a decision, and anyone else who was delegated commit access for robustness or convenience must then respect that decision. It's the only way to keep a project making progress at a reasonable pace. This is not a radical position. That's how nearly all coding projects work. I have been involved with open source for 15 years and the 'single maintainer who makes decisions' model is normal, even if in some large codebases subsystems have delegated submaintainers. This is also how all my own projects are run. Bitcoinj has multiple people with commit access. Regardless, if there were to be some design dispute or whatever, I wouldn't tolerate the others with commit access starting some kind of Wiki-style edit war in the code if they disagreed. Nor would I ever expect to get my own way in other people's projects by threatening to revert the maintainers changes. Core is in the weird position where there's no decision making ability at all, because anyone who shows up and shouts enough can generate 'controversy', then Wladimir sees there is disagreement and won't touch the issue in question. So it just runs and runs and *anyone* with commit access can then block any change. I realise some people think this anti-process leads to better decision making. I disagree. It leads to no decision making, which is not the same thing at all. --047d7b3a82e2e1ef050518c7df05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dude, calm down. I don't have commit access to Bitcoin= Core and Gavin already said long ago he wouldn't just commit something= , even though he has the ability to do so.

So why did I = say it? Because it's consistent with what I've always said: =C2=A0y= ou cannot run a codebase like Wikipedia. Maintainers have to take part in d= ebates, and then make a decision, and anyone else who was delegated commit = access for robustness or convenience must then respect that decision. It= 9;s the only way to keep a project making progress at a reasonable pace.

This is not a radical position. That's how nearl= y all coding projects work. I have been involved with open source for 15 ye= ars and the 'single maintainer who makes decisions' model is normal= , even if in some large codebases =C2=A0subsystems have delegated submainta= iners.

This is also how all my own projects are ru= n. Bitcoinj has multiple people with commit access. Regardless, if there we= re to be some design dispute or whatever, I wouldn't tolerate the other= s with commit access starting some kind of Wiki-style edit war in the code = if they disagreed. Nor would I ever expect to get my own way in other peopl= e's projects by threatening to revert the maintainers changes.

Core is in the weird position where there's no decisio= n making ability at all, because anyone who shows up and shouts enough can = generate 'controversy', then Wladimir sees there is disagreement an= d won't touch the issue in question. So it just runs and runs and an= yone=C2=A0with commit access can then block any change.

<= /div>
I realise some people think this anti-process leads to better dec= ision making. I disagree. It leads to no decision making, which is not the = same thing at all.
--047d7b3a82e2e1ef050518c7df05--