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