public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Michael Folkson <michaelfolkson@protonmail.com>
To: Anthony Towns <aj@erisian.com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Date: Thu, 20 Apr 2023 09:24:19 +0000	[thread overview]
Message-ID: <WDVwDUeYiJoJ_pfvagNC7JVoZEacE_MU_MHkS1GHgxV1arDZcCOdEwKf-5vX9CkHsMFsXtHVrYLFAEHAwmkgVEsqdRhUGIJIyCDr5EPr4_Y=@protonmail.com> (raw)
In-Reply-To: <ZECjAWr1cYtBKb+U@erisian.com.au>

Hi AJ

> Competition is the only answer to concerns about the bad effects from a monopoly.

Well one can first make suggestions and requests to the monopoly and see if the monopoly is open to them. In the case of bitcoin-inquisition/default signet I like the idea of a group who are interested in following and testing proposed future consensus changes working on the same fork of Core / same signet blockchain. But I've asked on a number of occasions now what the thinking is in terms of criteria for merging a proposed default policy change or a proposed consensus change (progress on BIP, level of review, a work in progress / still in flux / essentially finalized unless a problem is identified) and you haven't been willing to discuss it. So it is essentially the same black box model of maintainership we see on Core. As far as I know you could wake up one day and just merge all open pull requests to the bitcoin-inquisition repo because you're bored. On a custom signet do whatever you want. On the default signet that we're trying to build an ecosystem around, get block explorers to support, can be connected to through the default config in Core etc merge decisions essentially being subject to the whims of AJ doesn't seem ideal to me.

The brunt of having to deal with the CTV activation chaos fell on me (not a long term contributor, unfunded) because few wanted to get involved so it would be nice if lessons were learned and we don't have a soft fork proposal merged onto default signet, a bunch of transactions generated to simulate demand and then this used to justify another contentious soft fork activation attempt on mainnet. When there are vacuums of communication from maintainers and long term contributors it just invites unnecessary chaos.

Thanks
Michael


--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3


------- Original Message -------
On Thursday, April 20th, 2023 at 03:27, Anthony Towns <aj@erisian.com.au> wrote:


> On Tue, Apr 18, 2023 at 12:40:44PM +0000, Michael Folkson via bitcoin-dev wrote:
> 
> > I do think the perception that it is “the one and only” staging
> > ground for consensus changes is dangerous
> 
> 
> If you think that about any open source project, the answer is simple:
> create your own fork and do a better job. Competition is the only answer
> to concerns about the bad effects from a monopoly. (Often the good effects
> from cooperation and collaboration -- less wasted time and duplicated
> effort -- turn out to outweigh the bad effects, however)
> 
> In any event, inquisition isn't "the one and only staging ground for
> consensus changes" -- every successful consensus change to date has
> been staged through the developers' own repo then the core PR process,
> and that option still exists.
> 
> Cheers,
> aj


  reply	other threads:[~2023-04-20  9:24 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 12:40 [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions Michael Folkson
2023-04-19  0:56 ` Erik Aronesty
2023-04-19 10:09   ` Michael Folkson
2023-04-19 12:24 ` alicexbt
2023-04-19 13:33   ` Michael Folkson
2023-04-19 21:13     ` alicexbt
2023-04-19 15:17 ` Aymeric Vitte
2023-04-19 21:33 ` Andrew Chow
2023-04-20  8:45   ` Michael Folkson
2023-04-20 10:54   ` Aymeric Vitte
2023-04-20 13:59     ` Erik Aronesty
2023-04-20 14:25       ` Aymeric Vitte
2023-04-20  2:27 ` Anthony Towns
2023-04-20  9:24   ` Michael Folkson [this message]
2023-05-07  7:03 ` Michael Folkson
2023-05-07 17:35   ` David A. Harding
2023-05-08  9:36     ` Michael Folkson
2023-05-08 12:03     ` Bryan Bishop
2023-05-10  2:44       ` Steve Lee
2023-05-10 15:55         ` Michael Folkson
2023-05-10 16:36           ` Steve Lee
2023-05-10 17:22             ` Michael Folkson
2023-05-10 18:29               ` Steve Lee
2023-05-10 21:24   ` Andrew Chow
2023-05-11 12:34     ` Michael Folkson
2023-05-11 16:49     ` alicexbt
2023-05-11 18:04       ` Steve Lee
2023-05-11 18:48         ` Erik Aronesty

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='WDVwDUeYiJoJ_pfvagNC7JVoZEacE_MU_MHkS1GHgxV1arDZcCOdEwKf-5vX9CkHsMFsXtHVrYLFAEHAwmkgVEsqdRhUGIJIyCDr5EPr4_Y=@protonmail.com' \
    --to=michaelfolkson@protonmail.com \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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