These are the kind of silly responses you often get when this subject
comes up. Mr. Garzik knows how to ignore messages he doesn't want so I
see no need for him to use the list to attack people he doesn't agree
with and/or try to interfere with discussions of others on the list.
He turns it into a personality discussion rather than a discussion of
Systems Engineering. He also tries to intimate anyone who brings up the
discussion and "punish" them as a lesson to anyone else who may raise
the issue.
It is interesting that people like that are attracted to a decentralized
system. The reply is simply an attempt at protecting turf which is why
Mr. Garzik's vague replies are never taken seriously on the subject of
decision-making process for the software.
Russ
On 6/25/2015 1:07 AM, Jeff Garzik wrote:
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 <mi...@bitcoins.info
<mailto:mi...@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
<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
<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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
