From: Bryan Bishop <kanzure@gmail•com>
To: Mike Hearn <mike@plan99•net>, Bryan Bishop <kanzure@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Thu, 18 Jun 2015 09:33:24 -0500 [thread overview]
Message-ID: <CABaSBaxN+tUV0zoPLoJJ-ooBVsT1cg9U+9ge4Xw78d+3Be6LJA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4553 bytes --]
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn <mike@plan99•net> wrote:
> Dude, calm down.
>
Well hold on, his concerns are real and he seems perfectly calm to me and
others apparently.
> and Gavin already said long ago he wouldn't just commit something, even
> though he has the ability to do so.
>
Nobody is worried about Gavin or anyone else making commits to git
repositories. You'll notice that this wasn't even mentioned in the original
email you were replying to. Instead, the email was talking about commit
access, which is a property of GitHub's repositories.
So why did I say it? Because it's consistent with what I've always said:
>
(That's not a good reason.)
you cannot run a codebase like Wikipedia
>
Wikipedia is a top-down centralized authority-based hierarchy. That's
pretty close to what you're proposing. That's what everyone else is
disagreeing with. You seem to have switched your position mid-flight...?
This is not a radical position. That's how nearly all coding projects work.
> I have been involved with open source for 15 years and the 'single
> maintainer who makes decisions' model is normal, even if in some large
> codebases subsystems have delegated submaintainers.
There are a number of reasons why that perspective is broken; throughout
our conversations others have repeatedly reminded you (such as in -wizards)
that forking an open-source repository is not at all like a hard-fork of
the blockchain. Anyone can be glorious leader of any repository they want,
that's how open-source works. However, it's critical that bitcoin users are
never convinced to trust BDFLs or anything else that can be compromised.
Should all bitcoin users suddenly start using software with BDFLs, even
multiple implementations with separate BDFLs, then those users can be
trivially compromised through their trust in those individuals and projects.
The alternative is that every developer and every user is personally
responsible for self-validation of the rules, checking for correctness and
validity. Happy coincidence that this seems to match the strategy of
operating the bitcoin network itself, which is to run a node that sees
everything and validates all the transactions. Anyone is able to find an
error in logic or flaw in the system rules, and they should make it known
as widely as possible so that others may evaluate the evidence and consider
which solutions preserve the important properties of the system. This is
not a matter of majorities or minorities; these arguments should be true
for anyone independent of who or what they are, or what level of
unpopularity they may have.
Anything other than this is somewhat radical, and I am confused as to why
others have been talking about "developer consensus". I suspect that the
reason why they have been saying developer consensus is because they are
talking about the Bitcoin Core project on GitHub at the moment. But the
topic switched to contentious hard-forks already, which is not a topic of
repositories but a topic of the blockchain and network; and in the context
of contentious hard-forks it is clear why everyone individually must
evaluate the rules and decide whether they the software is correct, or
whether changes can trivially cause catastrophic broken hard-forks. These
lines of reasoning should be true for everyone, and not merely true for one
person but not another. Users, companies and developers must be aware of
this, even though it's different from their usual expectations of how
systems operate and are maintained. And it is important to be careful to
not misconstrue this to others because it is entirely possible to
unintentionally convince others that traditional and centralized models are
safely applicable here.
I realise some people think this anti-process leads to better decision
> making. I disagree. It leads to no decision making, which is not the same
> thing at all.
>
Well, if you're talking about the recent disputes regarding a certain patch
to hard-fork the blockchain, a decision to not include such a patch seems
like the very definition of a decision.
Gavin and I say - there is a process, and that process is a hard fork of
> the block chain.
I doubt that other bitcoin software maintainers would agree with that sort
of toxic reasoning; contentious hard-forks are basically a weapon of war
that you can use against any other collaborator on any bitcoin project. Why
would anyone want to collaborate on such a hostile project? How would they
even trust each other?
- Bryan
http://heybryan.org/
1 512 203 0507
[-- Attachment #2: Type: text/html, Size: 6864 bytes --]
next prev parent reply other threads:[~2015-06-18 14:33 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 8:54 odinn
2015-06-18 10:00 ` Mike Hearn
2015-06-18 11:14 ` Wladimir J. van der Laan
2015-06-18 11:47 ` Wladimir J. van der Laan
2015-06-18 13:36 ` Mike Hearn
2015-06-18 15:58 ` Gregory Maxwell
2015-06-18 12:29 ` Pieter Wuille
2015-06-18 12:50 ` Wladimir J. van der Laan
2015-06-18 12:56 ` Benjamin
2015-06-18 13:49 ` Mike Hearn
2015-06-18 14:05 ` Wladimir J. van der Laan
2015-06-18 14:16 ` Mike Hearn
2015-06-18 14:53 ` Milly Bitcoin
2015-06-18 14:56 ` Jeff Garzik
2015-06-18 15:13 ` Milly Bitcoin
2015-06-18 14:53 ` Jeff Garzik
2015-06-18 16:07 ` justusranvier
2015-06-18 16:28 ` Jeff Garzik
2015-06-18 17:04 ` justusranvier
2015-06-18 17:42 ` Alex Morcos
2015-06-18 18:01 ` Milly Bitcoin
2015-06-18 18:23 ` Gavin Andresen
2015-06-18 18:44 ` Alex Morcos
2015-06-18 18:49 ` Jorge Timón
2015-06-18 19:31 ` Ross Nicoll
2015-06-18 21:42 ` Matt Whitlock
2015-06-18 21:49 ` Mark Friedenbach
2015-06-18 21:58 ` Jeff Garzik
2015-06-18 22:33 ` Mark Friedenbach
2015-06-18 22:52 ` Jeff Garzik
2015-06-18 23:25 ` odinn
2015-06-18 23:16 ` Ross Nicoll
2015-06-19 0:57 ` Chris Pacia
2015-06-19 5:59 ` Eric Lombrozo
2015-06-19 9:37 ` Mike Hearn
2015-06-19 9:53 ` Benjamin
2015-06-19 10:08 ` GC
2015-06-19 10:19 ` Mike Hearn
2015-06-19 10:52 ` Eric Lombrozo
2015-06-19 11:31 ` Jorge Timón
2015-06-19 12:26 ` GC
2015-06-19 11:48 ` Brooks Boyd
2015-06-21 14:45 ` Owen Gunden
2015-06-18 21:55 ` Ross Nicoll
2015-06-18 19:24 ` Matt Corallo
2015-06-18 19:32 ` Gregory Maxwell
2015-06-18 12:38 ` Milly Bitcoin
2015-06-18 13:31 ` Mike Hearn
2015-06-18 13:50 ` Pieter Wuille
2015-06-18 15:03 ` Mark Friedenbach
2015-06-18 15:30 ` Milly Bitcoin
2015-06-18 15:46 ` Wladimir J. van der Laan
2015-06-18 16:05 ` Mike Hearn
2015-06-18 16:20 ` Wladimir J. van der Laan
2015-06-18 22:49 ` odinn
2015-06-18 16:11 ` Milly Bitcoin
2015-06-18 11:41 ` Lawrence Nahum
2015-06-18 14:33 ` Bryan Bishop [this message]
2015-06-18 18:09 ` Melvin Carvalho
2015-06-18 22:10 ` odinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABaSBaxN+tUV0zoPLoJJ-ooBVsT1cg9U+9ge4Xw78d+3Be6LJA@mail.gmail.com \
--to=kanzure@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox