rich1.0npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wthttps://nostr.ae/npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wtnjumphttps://nostr.ae📅 Original date posted:2015-06-25 📝 Original message: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 <milly at bitcoins.info > <mailto:milly at 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 at bitcoins.info <mailto:milly at 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 at lists.linuxfoundation.org >> <mailto:bitcoin-dev at lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> <mailto:bitcoin-dev at lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > <mailto:bitcoin-dev at lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/3deb2320/attachment.html>