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 <mi...@bitcoins.info
<mailto:mi...@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
<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
<mailto: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