Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AD966E41 for ; Sat, 5 Sep 2015 21:20:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4203D254 for ; Sat, 5 Sep 2015 21:20:11 +0000 (UTC) Received: by ioiz6 with SMTP id z6so56340834ioi.2 for ; Sat, 05 Sep 2015 14:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iWsbWJ+C7sghhYtBRQcIapdUtcbOQHaZN5YYWG4pqXg=; b=dL7VKK7CqHfHCwWCa/eHz0r+0tAgvdgu4NXkdjLT/l8I5LCbDW4dTDRc3sNGLGX0aA 6Powqf8T00gD0HcOzCBeeQ5Az1SWk8bdCmpw2Ms2e1wOaKC7loAh46CJoKUbmMcE3Gxj XJgqocgHCavdSD4shyECrV0/ShE9mvRtMYz6IBC9oUR0iav01U71ULievvt0/Mr5cnxS oKZrFWRRk5HPDs5i90a48S3zEiGmoeLmdAk2hu5/eNdyjPtIWo7plw4BH84kUtEfgy7I ZN+Ds1SyItfH8jlxjjJ3SoyWwOEDBWb+EJGRyGoh05+ZpH9ZEUB9vwwWBMos1sURcjPW HJnA== X-Received: by 10.107.166.139 with SMTP id p133mr18629467ioe.113.1441488010686; Sat, 05 Sep 2015 14:20:10 -0700 (PDT) MIME-Version: 1.0 Sender: asperous2@gmail.com Received: by 10.50.3.33 with HTTP; Sat, 5 Sep 2015 14:19:51 -0700 (PDT) In-Reply-To: <201509042145.34410.luke@dashjr.org> References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com> <201509042101.11839.luke@dashjr.org> <201509042145.34410.luke@dashjr.org> From: Andy Chase Date: Sat, 5 Sep 2015 14:19:51 -0700 X-Google-Sender-Auth: w1GuDhSwolnL5vMWjGFCg3GXy04 Message-ID: To: Luke Dashjr , gmaxwell@gmail.com Content-Type: multipart/alternative; boundary=001a1141ef3cd337ab051f0694d5 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 21:20:11 -0000 --001a1141ef3cd337ab051f0694d5 Content-Type: text/plain; charset=UTF-8 Okay for sure yeah writing another proposal that reflects the current state of affairs as people see it might provide some interesting perspective on this proposal. I would welcome that. Greg: With no other direct comments appearing to be inbound I'd like to move forward with this one and get a number assigned to it. Thanks! Thanks to all for the discussion! On Fri, Sep 4, 2015 at 2:45 PM, Luke Dashjr wrote: > On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote: > > I understand your concerns. What kinds of changes do you think should go > > through a process like this? Just hard forks? > > The process loses meaning if it doesn't reflect reality. So only hardforks > should go through the hardfork process; only softforks through the softfork > process; etc. Trying to make one-size-fits-all just means de facto accepted > BIPs wouldn't be recognised as such because nobody cares to meet the higher > requirements. > > Luke > --001a1141ef3cd337ab051f0694d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay for sure yeah writing another proposal that reflects = the current state of affairs as people see it might provide some interestin= g perspective on this proposal. I would welcome that.

Gr= eg: With no other direct comments appearing to be inbound I'd like to m= ove forward with this one and get a number assigned to it. Thanks!

Thanks to all for the discussion!

On Fri, Sep 4, 2015 at 2:45 PM= , Luke Dashjr <luke@dashjr.org> wrote:
On Friday, September 04, 2015 9:36:42 PM Andy C= hase wrote:
> I understand your concerns. What kinds of changes do you think should = go
> through a process like this? Just hard forks?

The process loses meaning if it doesn't reflect reality. So only= hardforks
should go through the hardfork process; only softforks through the softfork=
process; etc. Trying to make one-size-fits-all just means de facto accepted=
BIPs wouldn't be recognised as such because nobody cares to meet the hi= gher
requirements.

Luke

--001a1141ef3cd337ab051f0694d5--