From: Alex Morcos <morcos@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Wed, 24 Jun 2015 22:30:53 -0400 [thread overview]
Message-ID: <CAPWm=eWJ+uOWO+x8mAWuQMy4EKZetOJvq6TeCsZ8uypnXEMEBQ@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4915 bytes --]
+1 Mark!
On Wed, Jun 24, 2015 at 9:50 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> I'm sorry but this is absolutely not the case, Milly. The reason that
> people get defensive is that we have a carefully constructed process that
> does work (thank you very much!) and is well documented. We talk about it
> quite often in fact as it is a defining characteristic of how bitcoin is
> developed which differs in some ways from how other open source software is
> developed -- although it remains the same in most other ways.
>
> Changes to the non-consensus sections of Bitcoin Core tend to get merged
> when there are a few reviews, tests, and ACKs from recognized developers,
> there are no outstanding objections, and the maintainer doing the merge
> makes a subjective judgement that the code is ready.
>
> Consensus-changes, on the other hand, get merged into Bitcoin Core only
> after the above criteria are met AND an extremely long discussion period
> that has given all the relevant stakeholders a chance to comment, and no
> significant objections remain. Consensus-code changes are unanimous. They
> must be.
>
> The sort of process that exists in standards bodies for example, with
> working groups and formal voting procedures, has no place where changes
> define the nature and validity of other people's money. Who has the right
> to reach into your pocket and define how you can or cannot spend your
> coins? The premise of bitcoin is that no one has that right, yet that is
> very much what we do when consensus code changes are made. That is why when
> we make a change to the rules governing the nature of bitcoin, we must make
> sure that everyone is made aware of the change and consents to it.
>
> Everyone. Does this work? Does this scale? So far, it does.
> Uncontroversial changes, such as BIP 66, are deployed without issue. Every
> indication is that BIP 66 will complete deployment in the very near future,
> and we intend to repeat this process for more interesting changes such as
> BIP65: CHECKLOCKTIMEVERIFY.
>
> This isn't about no one stepping forward to be the "decider." This is
> about no one having the right to decide these things on the behalf of
> others. If a contentious change is proposed and not accepted by the process
> of consensus, that is because the process is doing its job at rejecting
> controversial changes. It has nothing to do with personality, and
> everything to do with the nature of bitcoin itself.
>
>
> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly@bitcoins.info>
> wrote:
>
>> I have seen this question asked many times. Most developers become
>> defensive and they usually give a very vague 1-sentence answer when this
>> question is asked. It seems to be it is based on personalities rather than
>> any kind of definable process. To have that discussion the personalities
>> must be separated out and answers like "such-and-such wouldn't do that"
>> don't really do much to advance the discussion. Also, the incentive for
>> new developers to come in is that they will be paid by companies who want
>> to influence the code and this should be considered (some developers take
>> this statement as an insult when it is just a statement of the incentive
>> process).
>>
>> The other problem you are having is the lead developer does not want to
>> be a "decider" when, in fact, he is a very significant decider. While the
>> users have the ultimate choice in a practical sense the chief developer is
>> the "decider." Now people don't want to get him upset so nobody wants to
>> push the issue or fully define the process. Now you are left with a
>> broken, unwritten/unspoken process. While this type of thing may work with
>> a small group of developers businesses/investors looking in from the
>> outside will see this as a risk.
>>
>> Until you get passed all the personality-based arguments you are going to
>> have a tough time defining a real process.
>>
>> Russ
>>
>>
>>
>>
>>
>>
>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>
>>> I would like to start a civil discussion on an undefined, or at least
>>> unwritten, portion of the BIP process. Who should get to vote on approval
>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>>> these voters sufficient for approval? If not, then what is?
>>>
>>> Raystonn
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 6392 bytes --]
next prev parent reply other threads:[~2015-06-25 2:30 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-24 23:41 [bitcoin-dev] BIP Process and Votes Raystonn
2015-06-24 23:49 ` Jeff Garzik
2015-06-25 0:11 ` Bryan Bishop
2015-06-25 0:21 ` Milly Bitcoin
2015-06-25 0:07 ` Milly Bitcoin
2015-06-25 1:50 ` Mark Friedenbach
2015-06-25 2:30 ` Alex Morcos [this message]
2015-06-25 2:34 ` Milly Bitcoin
2015-06-25 5:07 ` Jeff Garzik
2015-06-25 5:41 ` Milly Bitcoin
2015-06-25 6:06 ` Pindar Wong
2015-06-25 6:15 ` Mark Friedenbach
2015-06-25 6:16 ` Warren Togami Jr.
2015-06-25 6:27 ` Pindar Wong
2015-06-25 7:51 ` cipher anthem
2015-06-25 10:09 ` nxtchg
2015-06-25 12:42 ` Milly Bitcoin
2015-06-25 20:05 ` Tier Nolan
2015-06-26 0:42 ` Milly Bitcoin
2015-07-01 22:34 ` odinn
2015-06-25 3:42 ` Gareth Williams
2015-06-25 4:10 ` Milly Bitcoin
2015-06-25 13:36 ` s7r
2015-06-25 13:41 ` Eric Lombrozo
2015-06-25 13:51 ` s7r
2015-06-25 14:08 ` Milly Bitcoin
2015-06-25 17:03 ` Jeff Garzik
2015-06-25 17:29 ` Milly Bitcoin
2015-06-25 0:18 Raystonn
2015-06-25 3:00 Raystonn
2015-06-25 3:19 ` Milly Bitcoin
2015-06-26 11:13 ` Jorge Timón
2015-06-26 12:34 ` Milly Bitcoin
2015-06-27 11:28 ` Jorge Timón
2015-06-27 12:50 ` Milly Bitcoin
2015-06-28 12:30 ` Jorge Timón
2015-06-28 13:13 ` Milly Bitcoin
2015-06-28 15:35 ` Jorge Timón
2015-06-28 16:23 ` Milly Bitcoin
2015-06-28 19:05 ` Patrick Murck
2015-06-28 20:10 ` Milly Bitcoin
2015-06-28 20:16 ` Mark Friedenbach
2015-06-28 20:26 ` Ricardo Filipe
2015-06-28 21:00 ` Adam Back
2015-06-29 0:13 ` Milly Bitcoin
2015-06-29 0:23 ` Andrew Lapp
2015-06-29 1:11 ` Milly Bitcoin
2015-06-28 23:52 ` Milly Bitcoin
2015-06-28 20:21 ` NxtChg
2015-06-25 19:03 ` Tom Harding
2015-06-25 3:53 Raystonn
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='CAPWm=eWJ+uOWO+x8mAWuQMy4EKZetOJvq6TeCsZ8uypnXEMEBQ@mail.gmail.com' \
--to=morcos@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=mark@friedenbach.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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