Re: [bitcoin-dev] BIP Process and Votes

From: Jeff Garzik <jgarzik@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
Date: Wed, 24 Jun 2015 22:07:26 -0700	[thread overview]
Message-ID: <CADm_WcZ+5z-7KDsOaNunSWAROoJEsDSEAFZ-d2C6cZBrQTkBcw@mail.gmail.com> (raw)
In-Reply-To: <558B68C3.9050608@bitcoins.info>

[-- Attachment #1: Type: text/plain, Size: 7192 bytes --]

Ladies & gents, please do not feed the troll.  This has been explained to
Milly multiple times in the past, on previous mailing list & github with no
impact.

On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly@bitcoins•info> wrote:

>  I'm sorry but that is the kind of defensive, cultish response everyone
> gets when they ask that question.  If you had a well constructed documented
> process then you would be able to point to it ... but you can't.  While
> there are a few bits and pieces scattered  about in different places there
> is no coherent plan or process.
>
> It is easy to make statements like "consensus must be unanimous" but the
> issue is that you never have true 100% consensus yet you have to move
> forward in some fashion and everyone has to run software with the same
> consensus rules.  The issue is how you move forward is the question that
> nobody wants to answer because (a) it is a hard question to answer and (b)
> developers see it as a threat to their authority/position.  If people just
> keep shutting down the discussion with a bunch of cultish stock answers
> then you are never going to move forward with developing some kind of
> process.
>
> From what I can see much of the discussion is personality-driven and not
> based on Computer Science or and defined process.  The issue is that a
> personality has changed so the process is perceived to be different and
> some people want to hard fork.  Previously, the cultish answer is that
> Bitcoin development is decentralized because people can fork the code.  Now
> that some developers want to fork the code suddenly it is a big problem.
> Is forking the code part of the consensus process or is it the work of the
> devil?   The fact that there is so much diverse opinion on this shows a
> defined process has never been fully vetted or understood.
>
> I have worked on these processes for many years for projects orders of
> magnitudes larger than Bitcoin.  I can absolutely assure you the current
> mishmash does not scale and huge amounts of time are wasted.  That should
> be readily apparent from the recent discussions and the recent concern it
> has caused from people outside the developer's inner circle.
>
> Lack of defined process = high risk and wasted effort.
>
> Russ
>
>
>
>
>
> On 6/24/2015 9:50 PM, Mark Friedenbach 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>
> 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: 11792 bytes --]