Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-19 📝 Original message:On Wed, Aug 19, 2015 at ...
📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 06:32:14PM +0100, Btc Drak via bitcoin-dev wrote:
> On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > ignored the warnings. Many also warned that 75% was an optimally BAD
> > trigger ratio (and that in a hard fork it is not a miner vote really
> > as in soft-forks). Gavin & Mike ignored that warning to. I know they
> > heard those warnings because I told them 1:1 in person or via email
> > and had on going conversations. Others did too.
>
> I would like to add for the record, I also warned Gavin of this in his
> PR to Bitcoin Core, and also suggested a timeout which if
> activation/enforcement did not occur within, hard fork deployment
> would be cancelled. His response was to delete these from the PR
> claiming thresholds were not relevant conversation in his PR and
> belonged elsewhere (even though they had already been discussed
> elsewhere).
Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
other users' comments on their own pull-reqs...
IMO that's an abuse of the pull-req process, and in turn, Gavin
Andresens's commit access rights for the Bitcoin Core repo.
That kind of comment is perfectly on topic in the pull-req review
process; deleting it harms that process by removing useful information
about the trade-offs of the pull-req, both for people now, as well as
future efforts investigating the history of Bitcoin's protocol
development.
I think this should weigh in favor of Gavin Andresen not having commit
privileges for the Bitcoin Core repository.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/9cd1e7da/attachment.sig>;
📝 Original message:On Wed, Aug 19, 2015 at 06:32:14PM +0100, Btc Drak via bitcoin-dev wrote:
> On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > ignored the warnings. Many also warned that 75% was an optimally BAD
> > trigger ratio (and that in a hard fork it is not a miner vote really
> > as in soft-forks). Gavin & Mike ignored that warning to. I know they
> > heard those warnings because I told them 1:1 in person or via email
> > and had on going conversations. Others did too.
>
> I would like to add for the record, I also warned Gavin of this in his
> PR to Bitcoin Core, and also suggested a timeout which if
> activation/enforcement did not occur within, hard fork deployment
> would be cancelled. His response was to delete these from the PR
> claiming thresholds were not relevant conversation in his PR and
> belonged elsewhere (even though they had already been discussed
> elsewhere).
Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
other users' comments on their own pull-reqs...
IMO that's an abuse of the pull-req process, and in turn, Gavin
Andresens's commit access rights for the Bitcoin Core repo.
That kind of comment is perfectly on topic in the pull-req review
process; deleting it harms that process by removing useful information
about the trade-offs of the pull-req, both for people now, as well as
future efforts investigating the history of Bitcoin's protocol
development.
I think this should weigh in favor of Gavin Andresen not having commit
privileges for the Bitcoin Core repository.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/9cd1e7da/attachment.sig>;