Peter Todd [ARCHIVE] on Nostr: š Original date posted:2015-08-20 š Original message:On Thu, Aug 20, 2015 at ...
š
Original date posted:2015-08-20
š Original message:On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via bitcoin-dev wrote:
> >
> > It is just that no one else is reckless enough to bypass the review process
>
>
> I keep seeing this notion crop up.
>
> I want to kill this idea right now:
>
> - There were months of public discussion leading to up the authoring of
> BIP 101, both on this mailing list and elsewhere.
>
> - BIP 101 was submitted for review via the normal process. Jeff Garzik
> specifically called Gavin out on Twitter and thanked him for following the
> process:
>
> https://twitter.com/jgarzik/status/614412097359708160
>
> https://github.com/bitcoin/bips/pull/163
>
> As you can see, other than a few minor typo fixes and a comment by sipa,
> there was no other review offered.
>
> - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
> request, to invoke the code review process:
>
> https://github.com/bitcoin/bitcoin/pull/6341
>
> Some minor code layout suggestions were made by Cory and incorporated.
> Peter popped up to say there was no chance it'd ever be accepted ..... and
> no further review was done.
No, I said there was no chance it'd be accepted "due to a number of
BIP-level issues in addition to debate about the patch itself. For
instance, Gavin has never given any details about testing; at minimum
we'd need a BIP16 style quality assurance document. We also frown on
writing software with building expiration dates, let alone expiration
dates that trigger non-deterministically. (Note how my recently merged
CLTV considered the year 2038 problem to avoid needing a hard fork at
that date)"
Of course no further review was done - issues were identified and they
didn't get fixed. Why would we do further review on something that was
broken whose author wasn't interested in fixing even non-controversial
and obvious problems?
The process is to do review, fix issues identified, and repeat until all
issues are fixed.
--
'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/20150820/d1842615/attachment-0001.sig>;
š Original message:On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via bitcoin-dev wrote:
> >
> > It is just that no one else is reckless enough to bypass the review process
>
>
> I keep seeing this notion crop up.
>
> I want to kill this idea right now:
>
> - There were months of public discussion leading to up the authoring of
> BIP 101, both on this mailing list and elsewhere.
>
> - BIP 101 was submitted for review via the normal process. Jeff Garzik
> specifically called Gavin out on Twitter and thanked him for following the
> process:
>
> https://twitter.com/jgarzik/status/614412097359708160
>
> https://github.com/bitcoin/bips/pull/163
>
> As you can see, other than a few minor typo fixes and a comment by sipa,
> there was no other review offered.
>
> - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
> request, to invoke the code review process:
>
> https://github.com/bitcoin/bitcoin/pull/6341
>
> Some minor code layout suggestions were made by Cory and incorporated.
> Peter popped up to say there was no chance it'd ever be accepted ..... and
> no further review was done.
No, I said there was no chance it'd be accepted "due to a number of
BIP-level issues in addition to debate about the patch itself. For
instance, Gavin has never given any details about testing; at minimum
we'd need a BIP16 style quality assurance document. We also frown on
writing software with building expiration dates, let alone expiration
dates that trigger non-deterministically. (Note how my recently merged
CLTV considered the year 2038 problem to avoid needing a hard fork at
that date)"
Of course no further review was done - issues were identified and they
didn't get fixed. Why would we do further review on something that was
broken whose author wasn't interested in fixing even non-controversial
and obvious problems?
The process is to do review, fix issues identified, and repeat until all
issues are fixed.
--
'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/20150820/d1842615/attachment-0001.sig>;