From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ABAF61208 for ; Thu, 31 Dec 2015 23:30:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3EB1124 for ; Thu, 31 Dec 2015 23:30:11 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id to4so202066257igc.0 for ; Thu, 31 Dec 2015 15:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=lSXjo22mSjWj92BHvJ73Cb/d54USqtp6K07k3WDUK5Q=; b=cXDFzr9+5uS3Nymq8lZcEWdGbq9xicZfLSAESJu9siQ5DiCGYQlEZAIXZ7CiRbnoeF USCbgimXUN9y0VugH/GS87z7abv6nW41InmOdn4MOjGt4sBnrdXtcdA9MVPVVFdIKcc+ OTnmcRkbaGHSBQJ8sSnub/oy7/DOfOgFvhbmyB6dBGHKmYggozUfAPW/j+s58SifHFyu RH234GVMXdYsy3AlqqCukgNrUKM3o8GgqAf3EeZU3E9ImXAO7Q9C1dNUz9XbdxJ8RYkO mkj3PdfElN1691NVSXWfd/7usb3+Ow+vuisdojpIZdmRrv4zSAWmpTA0pdNdgOMLemsf ccSw== X-Received: by 10.50.112.137 with SMTP id iq9mr10105243igb.66.1451604611458; Thu, 31 Dec 2015 15:30:11 -0800 (PST) MIME-Version: 1.0 References: <20151231231440.GA5112@muck> In-Reply-To: <20151231231440.GA5112@muck> From: Adrian Macneil Date: Thu, 31 Dec 2015 23:30:02 +0000 Message-ID: To: Peter Todd , Marco Pontello Content-Type: multipart/alternative; boundary=089e013c60ec38719005283a09dc X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 X-Mailman-Approved-At: Thu, 31 Dec 2015 23:47:42 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] BIP numbers 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: Thu, 31 Dec 2015 23:30:12 -0000 --089e013c60ec38719005283a09dc Content-Type: text/plain; charset=UTF-8 I'm not sure if anyone has suggested this in the past, but a novel approach would be to simply let anyone open a pull request and use the PR # as the BIP #. This would avoid conflicts, and avoid the chore of having someone manually assign them. Downside would be that some numbers will never get used (for example if PRs are opened to update existing BIPs), but this doesn't seem to be a huge problem since already many numbers are going unused. This process can still be independent from approving/merging the BIP into master, if it meets quality standards. On Thu, Dec 31, 2015 at 3:14 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Dec 30, 2015 at 05:42:47PM +0100, Marco Pontello via bitcoin-dev > wrote: > > Sorry to ask again but... what's up with the BIP number assignments? > > I thought that it was just more or less a formality, to avoid conflicts > and > > BIP spamming. And that would be perfectly fine. > > But since I see that it's a process that can take months (just looking at > > the PR request list), it seems that something different is going on. > Maybe > > it's considered something that give an aura of officiality of sorts? But > > that would make little sense, since that should come eventually with > > subsequents steps (like adding a BIP to the main repo, and eventual > > approvation). > > > > Having # 333 assigned to a BIP, should just mean that's easy to refer to > a > > particular BIP. > > That seems something that could be done quick and easily. > > > > What I'm missing? Probably some historic context? > > You ever noticed how actually getting a BIP # assigned is the *last* > thing the better known Bitcoin Core devs do? For instance, look at the > segregated witness draft BIPs. > > I think we have problem with peoples' understanding of the Bitcoin > consensus protocol development process being backwards: first write your > protocol specification - the code - and then write the human readable > reference explaining it - the BIP. > > Equally, without people actually using that protocol, who cares about > the BIP? > > > Personally if I were assigning BIP numbers I'd be inclined to say "fuck > it" and only assign BIP numbers to BIPs after they've had significant > adoption... It'd might just cause a lot less headache than the current > system. > > -- > 'peter'[:-1]@petertodd.org > 000000000000000006808135a221edd19be6b5b966c4621c41004d3d719d18b7 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e013c60ec38719005283a09dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not sure if anyone has suggested this in the past, but a novel appr= oach would be to simply let anyone open a pull request and use the PR # as = the BIP #. This would avoid conflicts, and avoid the chore of having someon= e manually assign them.

Downside would be that some numbers will ne= ver get used (for example if PRs are opened to update existing BIPs), but t= his doesn't seem to be a huge problem since already many numbers are go= ing unused.

This process can still be independent from approving/me= rging the BIP into master, if it meets quality standards.
On Thu, Dec 31, 2015 at 3:14 PM Peter Todd v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Wed, Dec 30, 2015 at 05:42:47PM +0100, Marco Pontello= via bitcoin-dev wrote:
> Sorry to ask again but... what's up with the BIP number assignment= s?
> I thought that it was just more or less a formality, to avoid conflict= s and
> BIP spamming. And that would be perfectly fine.
> But since I see that it's a process that can take months (just loo= king at
> the PR request list), it seems that something different is going on. M= aybe
> it's considered something that give an aura of officiality of sort= s? But
> that would make little sense, since that should come eventually with > subsequents steps (like adding a BIP to the main repo, and eventual > approvation).
>
> Having # 333 assigned to a BIP, should just mean that's easy to re= fer to a
> particular BIP.
> That seems something that could be done quick and easily.
>
> What I'm missing? Probably some historic context?

You ever noticed how actually getting a BIP # assigned is the *last*
thing the better known Bitcoin Core devs do? For instance, look at the
segregated witness draft BIPs.

I think we have problem with peoples' understanding of the Bitcoin
consensus protocol development process being backwards: first write your protocol specification - the code - and then write the human readable
reference explaining it - the BIP.

Equally, without people actually using that protocol, who cares about
the BIP?


Personally if I were assigning BIP numbers I'd be inclined to say "= ;fuck
it" and only assign BIP numbers to BIPs after they've had signific= ant
adoption... It'd might just cause a lot less headache than the current<= br> system.

--
'peter'[:-1]@petertodd.org
000000000000000006808135a221edd19be6b5b966c4621c41004d3d719d18b7
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--089e013c60ec38719005283a09dc--